You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by "Hensley, Richard" <Ri...@McKesson.com> on 2004/12/09 18:29:28 UTC
Tapestry Property Management (was RE: Canonical way to share
data among page objects)
Actually, there is a Tapestry pattern affectionately known as the "Tapestry
Property Bucket Brigade".
The basics of the pattern are:
- Persistent properties are used to hold values on a single page from cycle
to cycle.
- When values are needed on a new page, the values are assigned to
properties on that page.
This impacts your application in practice by replacing page links with
simple listener methods that have the following pattern:
Get the page
Bucket Brigade properties to the page
Activate the page
We use this pattern quite frequently in our application. It helps reduce
Visit object clutter.
If you are using Tapestry 3.0, you declare persistent properties using the
following:
In the page specification file:
<page-specification class="package.PropClass">
<property name="prop" class="java.lang.String" persistent="yes" />
</page-specification>
And in your PropClass.java file:
public abstract class PropClass extends BasePage {
abstract String getProp();
abstract String setProp(String prop);
}
Because the class is abstract, and the bean style setters and getters are
abstract, and the property name is declared persistent in the specification,
Tapestry enhances the class by doing the following:
- Adding a member variable to store the value of prop
- Implement the getProp() method to return the member variable
- Implement the setProp() method to detect when the value changes so that
Tapestry is notified of the change so it can manage the persistent property
value into the session
Because the property was declared as persistent, Tapestry restores the value
of the property each time the cycle.getPage("MyPage") method is called.
If the property had not been declared as persistent, Tapestry ensures that
the value is initialized to the declared initial-value, or to the JVM
default initial-value.
If you use member variables, you must abide by all the above rules manually.
For persistent properties, this means calling Tapestry.fireObservedChange()
when a property changes.
For all properties, this means implementing the initialize() method to meet
the Tapestry specification regarding initialized variables.
If you don't manage your page member variables using these rules, you will
discover that seemingly random values are left over in your member
variables. This is because Tapestry caches page instances and reuses them
across thread boundaries.
If you are not seeing problems like this, you are doing some variation of
the following:
- You are running without the page specification cache enabled, a.k.a.
Tapestry Developer mode
- You have done some initializing of variables in the pageBeginRender() or
some other method.
- Your application is not vulnerable to left over values in member
variables.
David,
I don't have a sample application, but I hope this little essay will help
you to better understand how Tapestry manages properties.
If I'm completely off the track one of the experts can correct me.
Richard
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Tapestry Property Management (was RE: Canonical way to share data among page objects)
Posted by Marcus Brito <mb...@gmail.com>.
Just adding to Richard's worderful explanation: not all page
properties need to be persistent. More often than not, you'll have
pages with a couple of properties that will *always* be set before the
page is activated. Think about a "Product Details" page where you
always set the product ID before activating it. In this situation, you
don't need to make this property persistent, simplifying your
programming model and lightening Tapestry's session management.
-- Marcus Brito
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Tapestry Property Management (was RE: Canonical way to share data among page objects)
Posted by Howard Lewis Ship <hl...@gmail.com>.
Using pageBeginRender() is the correct way. Bear in mind that
pageBeginRender() will be invoked when the page renders normally, AND,
when any form within the page is submitted. For very expensive
operations that are not needed for the form rewind, you may want:
public void pageBeginRender(...)
{
if (getRequestCycle().isRewinding()) return;
// Very expensive operation ...
}
On Sun, 12 Dec 2004 23:28:09 -0800 (PST), David van Coevorden
<dv...@yahoo.com> wrote:
> Thank you Richard, that is indeed helpful. One question remains
> regarding initialization. I would like to initialize some properties
> typically, converting a lists and setting the results equal to the
> property. Do you suggest that, apart from doing the initialization
> yourself according to tapestry rules, you can also do it by using just
> local variables in pageBeginRender() e.g. and then calling setProp(List
> aList)?
>
> David
>
>
>
>
> --- "Hensley, Richard" <Ri...@McKesson.com> wrote:
>
> > Actually, there is a Tapestry pattern affectionately known as the
> > "Tapestry
> > Property Bucket Brigade".
> >
> > The basics of the pattern are:
> >
> > - Persistent properties are used to hold values on a single page from
> > cycle
> > to cycle.
> > - When values are needed on a new page, the values are assigned to
> > properties on that page.
> >
> > This impacts your application in practice by replacing page links
> > with
> > simple listener methods that have the following pattern:
> >
> > Get the page
> > Bucket Brigade properties to the page
> > Activate the page
> >
> > We use this pattern quite frequently in our application. It helps
> > reduce
> > Visit object clutter.
> >
> > If you are using Tapestry 3.0, you declare persistent properties
> > using the
> > following:
> >
> > In the page specification file:
> >
> > <page-specification class="package.PropClass">
> > <property name="prop" class="java.lang.String" persistent="yes" />
> > </page-specification>
> >
> > And in your PropClass.java file:
> >
> > public abstract class PropClass extends BasePage {
> >
> > abstract String getProp();
> > abstract String setProp(String prop);
> > }
> >
> > Because the class is abstract, and the bean style setters and getters
> > are
> > abstract, and the property name is declared persistent in the
> > specification,
> > Tapestry enhances the class by doing the following:
> >
> > - Adding a member variable to store the value of prop
> > - Implement the getProp() method to return the member variable
> > - Implement the setProp() method to detect when the value changes so
> > that
> > Tapestry is notified of the change so it can manage the persistent
> > property
> > value into the session
> >
> > Because the property was declared as persistent, Tapestry restores
> > the value
> > of the property each time the cycle.getPage("MyPage") method is
> > called.
> >
> > If the property had not been declared as persistent, Tapestry ensures
> > that
> > the value is initialized to the declared initial-value, or to the JVM
> > default initial-value.
> >
> > If you use member variables, you must abide by all the above rules
> > manually.
> >
> > For persistent properties, this means calling
> > Tapestry.fireObservedChange()
> > when a property changes.
> >
> > For all properties, this means implementing the initialize() method
> > to meet
> > the Tapestry specification regarding initialized variables.
> >
> > If you don't manage your page member variables using these rules, you
> > will
> > discover that seemingly random values are left over in your member
> > variables. This is because Tapestry caches page instances and reuses
> > them
> > across thread boundaries.
> >
> > If you are not seeing problems like this, you are doing some
> > variation of
> > the following:
> >
> > - You are running without the page specification cache enabled,
> > a.k.a.
> > Tapestry Developer mode
> > - You have done some initializing of variables in the
> > pageBeginRender() or
> > some other method.
> > - Your application is not vulnerable to left over values in member
> > variables.
> >
> > David,
> >
> > I don't have a sample application, but I hope this little essay will
> > help
> > you to better understand how Tapestry manages properties.
> >
> > If I'm completely off the track one of the experts can correct me.
> >
> > Richard
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> > tapestry-user-help@jakarta.apache.org
> >
> >
>
>
> __________________________________
> Do you Yahoo!?
> Jazz up your holiday email with celebrity designs. Learn more.
> http://celebrity.mail.yahoo.com
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Tapestry Property Management (was RE: Canonical way to share data among page objects)
Posted by David van Coevorden <dv...@yahoo.com>.
Thank you Richard, that is indeed helpful. One question remains
regarding initialization. I would like to initialize some properties
typically, converting a lists and setting the results equal to the
property. Do you suggest that, apart from doing the initialization
yourself according to tapestry rules, you can also do it by using just
local variables in pageBeginRender() e.g. and then calling setProp(List
aList)?
David
--- "Hensley, Richard" <Ri...@McKesson.com> wrote:
> Actually, there is a Tapestry pattern affectionately known as the
> "Tapestry
> Property Bucket Brigade".
>
> The basics of the pattern are:
>
> - Persistent properties are used to hold values on a single page from
> cycle
> to cycle.
> - When values are needed on a new page, the values are assigned to
> properties on that page.
>
> This impacts your application in practice by replacing page links
> with
> simple listener methods that have the following pattern:
>
> Get the page
> Bucket Brigade properties to the page
> Activate the page
>
> We use this pattern quite frequently in our application. It helps
> reduce
> Visit object clutter.
>
> If you are using Tapestry 3.0, you declare persistent properties
> using the
> following:
>
> In the page specification file:
>
> <page-specification class="package.PropClass">
> <property name="prop" class="java.lang.String" persistent="yes" />
> </page-specification>
>
> And in your PropClass.java file:
>
> public abstract class PropClass extends BasePage {
>
> abstract String getProp();
> abstract String setProp(String prop);
> }
>
> Because the class is abstract, and the bean style setters and getters
> are
> abstract, and the property name is declared persistent in the
> specification,
> Tapestry enhances the class by doing the following:
>
> - Adding a member variable to store the value of prop
> - Implement the getProp() method to return the member variable
> - Implement the setProp() method to detect when the value changes so
> that
> Tapestry is notified of the change so it can manage the persistent
> property
> value into the session
>
> Because the property was declared as persistent, Tapestry restores
> the value
> of the property each time the cycle.getPage("MyPage") method is
> called.
>
> If the property had not been declared as persistent, Tapestry ensures
> that
> the value is initialized to the declared initial-value, or to the JVM
> default initial-value.
>
> If you use member variables, you must abide by all the above rules
> manually.
>
> For persistent properties, this means calling
> Tapestry.fireObservedChange()
> when a property changes.
>
> For all properties, this means implementing the initialize() method
> to meet
> the Tapestry specification regarding initialized variables.
>
> If you don't manage your page member variables using these rules, you
> will
> discover that seemingly random values are left over in your member
> variables. This is because Tapestry caches page instances and reuses
> them
> across thread boundaries.
>
> If you are not seeing problems like this, you are doing some
> variation of
> the following:
>
> - You are running without the page specification cache enabled,
> a.k.a.
> Tapestry Developer mode
> - You have done some initializing of variables in the
> pageBeginRender() or
> some other method.
> - Your application is not vulnerable to left over values in member
> variables.
>
> David,
>
> I don't have a sample application, but I hope this little essay will
> help
> you to better understand how Tapestry manages properties.
>
> If I'm completely off the track one of the experts can correct me.
>
> Richard
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> tapestry-user-help@jakarta.apache.org
>
>
__________________________________
Do you Yahoo!?
Jazz up your holiday email with celebrity designs. Learn more.
http://celebrity.mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org