You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Ben Eng <be...@jetpen.com> on 2004/10/05 04:46:23 UTC

persist values of component parameters until listener is called

I am trying to persist the values of parameters into a component, so
that they can be used when a listener is called later. Is there a
supported way of doing this?

Through experimentation, I've discovered that the parameter values are
only made available to the renderComponent() method. However, within
that method, calling the setter of a persistent property is
disallowed, because it is after the commit point for the page
recorder. To force this to work, I manually implement the persistent
properties without firing an observed change.

The Tapestry documentation at
http://jakarta.apache.org/tapestry/doc/TapestryUsersGuide/state.manual-component-properties.html
also suggests to initialize the properties from finishLoad() and
pageDetached(). Unfortunately, this causes the property values to be
re-initialized before the listener is called by clicking on a
DirectLink from the page. I have to disable this initialization for
things to work.

Now that it apparently works, I feel confused about how this should be
done properly. I'm also worried that it's defective, because the page
detached event fires between the calls to renderComponent() and my
listener. Does this indicate that the component is returned to the
pool during that time? If so, I guess I can't trust that the persisted
component properties really belong to the state of the same session?

Can someone clear this situation up for me?

Ben

---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org


Re: persist values of component parameters until listener is called

Posted by Ben Eng <be...@jetpen.com>.
Jamie,

Your option #2 looked very promising, so I gave it a
try. Unfortunately, the property value is only set during
renderComponent(). I suspect that as the "in" parameter is reset after
rendering, it simply blows away the value from the connected property.

After reading the documentation a little more carefully, I see the
warning about direction="in" and direction="form" parameters being
unavailable to listeners. Since my parameters are optionally, I can't
use "auto". Since "custom" is a little tedious, I don't see it having
any advantage over the technique I'm already using to manually persist
properties, and setting them in renderComponet().

However, I'm still confused about why a pageDetached event occurs
between the time renderComponent() is called and my listener
method. What does this event mean?

Thanks for sharing your ideas with me. It helps me think this
through.

Ben

On Tue, Oct 05, 2004 at 12:04:32AM -0400, Jamie Orchard-Hays wrote:
> There are several approaches:
> 
> 1. persist the parameter in your page file:
>     <property-specification name="slot"  
> type="com.my.package.PersonalScheduleSlot" persistent="yes" />
> 
> 2. persist the parameter in your custom component by defining it in the  
> jwc file
>     <parameter
>         name="data"
>         type="java.lang.Object"
>         required="yes"
>         direction="in"
>         property-name="dataProperty" />
>     <property-specification name="dataProperty" type="java.lang.Object"  
> persistent="yes" />
> 
> You can probably do this somehow in the java file, but I haven't done  
> it because it's recommended to use the definition file to handle the  
> properties. See if you can get somewhere with that.
> 
> Jamie
> 	
> 
> On Oct 4, 2004, at 10:46 PM, Ben Eng wrote:
> 
> >I am trying to persist the values of parameters into a component, so
> >that they can be used when a listener is called later. Is there a
> >supported way of doing this?
> >
> >Through experimentation, I've discovered that the parameter values are
> >only made available to the renderComponent() method. However, within
> >that method, calling the setter of a persistent property is
> >disallowed, because it is after the commit point for the page
> >recorder. To force this to work, I manually implement the persistent
> >properties without firing an observed change.
> >
> >The Tapestry documentation at
> >http://jakarta.apache.org/tapestry/doc/TapestryUsersGuide/ 
> >state.manual-component-properties.html
> >also suggests to initialize the properties from finishLoad() and
> >pageDetached(). Unfortunately, this causes the property values to be
> >re-initialized before the listener is called by clicking on a
> >DirectLink from the page. I have to disable this initialization for
> >things to work.
> >
> >Now that it apparently works, I feel confused about how this should be
> >done properly. I'm also worried that it's defective, because the page
> >detached event fires between the calls to renderComponent() and my
> >listener. Does this indicate that the component is returned to the
> >pool during that time? If so, I guess I can't trust that the persisted
> >component properties really belong to the state of the same session?
> >
> >Can someone clear this situation up for me?
> >
> >Ben
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org


Re: persist values of component parameters until listener is called

Posted by Jamie Orchard-Hays <ja...@dang.com>.
There are several approaches:

1. persist the parameter in your page file:
     <property-specification name="slot"  
type="com.my.package.PersonalScheduleSlot" persistent="yes" />

2. persist the parameter in your custom component by defining it in the  
jwc file
     <parameter
         name="data"
         type="java.lang.Object"
         required="yes"
         direction="in"
         property-name="dataProperty" />
     <property-specification name="dataProperty" type="java.lang.Object"  
persistent="yes" />

You can probably do this somehow in the java file, but I haven't done  
it because it's recommended to use the definition file to handle the  
properties. See if you can get somewhere with that.

Jamie
	

On Oct 4, 2004, at 10:46 PM, Ben Eng wrote:

> I am trying to persist the values of parameters into a component, so
> that they can be used when a listener is called later. Is there a
> supported way of doing this?
>
> Through experimentation, I've discovered that the parameter values are
> only made available to the renderComponent() method. However, within
> that method, calling the setter of a persistent property is
> disallowed, because it is after the commit point for the page
> recorder. To force this to work, I manually implement the persistent
> properties without firing an observed change.
>
> The Tapestry documentation at
> http://jakarta.apache.org/tapestry/doc/TapestryUsersGuide/ 
> state.manual-component-properties.html
> also suggests to initialize the properties from finishLoad() and
> pageDetached(). Unfortunately, this causes the property values to be
> re-initialized before the listener is called by clicking on a
> DirectLink from the page. I have to disable this initialization for
> things to work.
>
> Now that it apparently works, I feel confused about how this should be
> done properly. I'm also worried that it's defective, because the page
> detached event fires between the calls to renderComponent() and my
> listener. Does this indicate that the component is returned to the
> pool during that time? If so, I guess I can't trust that the persisted
> component properties really belong to the state of the same session?
>
> Can someone clear this situation up for me?
>
> Ben
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org