You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Richard Perfect <ri...@rperfect.net> on 2003/11/19 19:32:28 UTC
Re[2]: Persistent properties
Hi Gereon,
The different sections are because one section is talking about
"automatic" properties and one section is talking about "manual"
properties. It is possible to simply declare a persistent property in
the page specification, use the property in the html template and not
include anything in the Page java class.
What's happening here is that Tapestry doesn't use *your* page class,
it extends it (creates a new class on the fly at runtime) and adds
extra getters/setters for the page persistent properties.
But if you do want to write your own getters and setters (because
other methods in your class need to call them) then you must also
include the line about fireObservedChange() because otherwise Tapestry
won't get to hear about any changes to the property.
GF> So in my understanding you just have to declare the property with
GF> persistent="yes". Is this right? Does this also work for changes in nested
GF> objects?
You need to...
* declare the property with persistent="yes"
* If you want your own setter method it needs to include the line
about fireObservedChange()
* If you want to use mutable/nested objects then anytime they change
something also needs to signal the fireObservedChange() - see the
previous emails.
- Richard.
Thursday, November 20, 2003, 3:49:09 AM, you wrote:
GF> Hi,
GF> I'm a bit confused about that. There are two sections about persistent
GF> properties in the documentation:
GF> Persistent Page Properties
GF> and
GF> Implementing Persistent Page Properties Manually
GF> In the first it is said that you just have do declare the property persistent.
GF> The second section notes the call of fireObservedChange() but also:
GF> "There is very little reason to implement persistent page properties manually."
GF> So in my understanding you just have to declare the property with
GF> persistent="yes". Is this right? Does this also work for changes in nested
GF> objects?
GF> Thanks,
GF> Gereon
>> Hi Glen,
>>
>> I'm pretty new to Tapestry so no doubt the 'old-weavers' will correct
>> me but since you're near my timezone and they're all asleep
>> at the moment here goes.
>>
>> If you change the value of a persistant property then you are expected
>> to signal this change to the framework with the following pattern;
>>
>> public void setPersonID(Long personID) {
>> this.personID = personID;
>> Tapestry.fireObservedChange(this, "personID", personID);
>> }
>>
>> If by mutable property you are talking about the Person object and not
>> just something like a person ID then you probably still have to do the
>> same sort of thing.
>>
>>
>> public void setPerson(Person person) {
>> this.person = person;
>> Tapestry.fireObservedChange(this, "person", person);
>> }
>>
>> public void someOtherMethod() {
>> person.setName("Joe Bloggs");
>> // now signal the change with either
>> setPerson(this.person);
>>
>> // Or...
>> Tapestry.fireObservedChange(this, "person", person);
>> }
>>
>> To be fair to the framework, it has to have someone tell it that
>> there's been a change because a persistant property gets stored off in
>> the HttpSession for all sorts of session and fail-over reasons.
>>
>> I suspect you're looking for an automatic way to deal with these
>> internal changes in which case you would probably need to put the
>> fireObservedChange() line into everyone of your mutable object's
>> setters. Which may or may not be a good thing depending on how often
>> updates are done and how expensive session persistence is.
>>
>> Hope this helps, ...surprised you're not watching Australian Idol...
>>
>> - Richard.
>>
>>
>>
>>
>>
>> Wednesday, November 19, 2003, 9:18:21 PM, you wrote:
>>
>>
>> GS> I just spend most of the day getting a deeper understanding of persistent
>> GS> properties.
>>
>> GS> What I discovered:
>>
>> GS> 1. Persistent properties don't get persisted unless they are marked as
>> GS> changed. This means that mutable objects that change their internal
GF> state
>> GS> don't get persisted (at least not by default) because hiberate doesn't
>> GS> record them as having changed.
>> GS> 2. Properties always get initialized before their persistent state is
>> GS> restored (or not restored). This isn't a big deal but can be a bit
>> GS> inefficient especially if your property initialization is doing some
GF> heavy
>> GS> work.
>>
>> GS> Now. As to point number 1. Is there any way for me to indicate that the
>> GS> internal state of my mutable property has changed? (I'm using the
GF> standard
>> GS> property-specification mechanism here).
>>
>> GS> Regards,
>>
>>
>> GS> Glen Stampoultzis
>> GS> gstamp@iinet.net.au
>> GS> http://members.iinet.net.au/~gstamp/glen/
>>
>>
>> GS> ---------------------------------------------------------------------
>> GS> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>> GS> 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
>>
>>
GF> ---------------------------------------------------------------------
GF> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
GF> 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: Persistent properties
Posted by Simon Raveh <si...@nominum.com>.
See comment incline
I've been using Tapestry for two month now, so I'm not sure how
accurate this information is.
Gereon Fassbender wrote:
>Hi Simon,
>
>
>
>>As I understand you can not implement only one method you will need to
>>implement both. I found out that if I need only the get or the set
>>method I add the abstract method for the set or the get and the
>>framework will include both.
>>
>>
>
>Are you sure? I had the same idea but couldn't get it working. I tried out
>these cases:
>1. implementing just one method
>
>
From my experience this will not work
>2. implementing both, read and write
>
>
This will work but you will need to be responsible for the
persistence and send the event.
>3. implementing read and adding an abstract method for write
>
>
Do not know
>It's true that you can choose between arbitrary abstract methods: none/one/both
>
>Gereon
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
>
>
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Persistent properties
Posted by Gereon Fassbender <gf...@startext.de>.
Hi Simon,
> As I understand you can not implement only one method you will need to
> implement both. I found out that if I need only the get or the set
> method I add the abstract method for the set or the get and the
> framework will include both.
Are you sure? I had the same idea but couldn't get it working. I tried out
these cases:
1. implementing just one method
2. implementing both, read and write
3. implementing read and adding an abstract method for write
It's true that you can choose between arbitrary abstract methods: none/one/both
Gereon
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Persistent properties
Posted by Simon Raveh <si...@nominum.com>.
Glen Stampoultzis wrote:
>
> Yeah, I've gotten the same error so I was thinking it must be wrong too.
>
> At 11:43 PM 20/11/2003, you wrote:
>
>> Hi Richard, hi Simon,
>>
>> thanks for your answers! It makes clear when event firing is necessary.
>> It is obvious that you have a deeper understanding of the enhancing
>> process.
>> Maybe you can also answer another question I wrote in the thread
>> "OGNL and
>> Enhancing Classes problems" some days ago:
>>
>> > to read or update the property. It is also valid to just implement one
>> > of the two accessors. The enhanced subclass will always include both a
>> > read and a write accessor.
>>
>> I have a problem with exactly this part of the documentation. I
>> defined a
>> property in the .jwc and implemented the get-method. But I get an
>> error that
>> the component can't be enhanced because the read method is implemented.
>> Is it possible that this excerpt of the documentation is just wrong?
>> Or otherwise where can I find a working example?
>>
>> Thanks,
>> Gereon
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
> Glen Stampoultzis
> gstamp@iinet.net.au
> http://members.iinet.net.au/~gstamp/glen/
>
As I understand you can not implement only one method you will need to
implement both. I found out that if I need only the get or the set
method I add the abstract method for the set or the get and the
framework will include both.
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Persistent properties
Posted by Glen Stampoultzis <gs...@iinet.net.au>.
Yeah, I've gotten the same error so I was thinking it must be wrong too.
At 11:43 PM 20/11/2003, you wrote:
>Hi Richard, hi Simon,
>
>thanks for your answers! It makes clear when event firing is necessary.
>It is obvious that you have a deeper understanding of the enhancing process.
>Maybe you can also answer another question I wrote in the thread "OGNL and
>Enhancing Classes problems" some days ago:
>
> > to read or update the property. It is also valid to just implement one
> > of the two accessors. The enhanced subclass will always include both a
> > read and a write accessor.
>
>I have a problem with exactly this part of the documentation. I defined a
>property in the .jwc and implemented the get-method. But I get an error that
>the component can't be enhanced because the read method is implemented.
>Is it possible that this excerpt of the documentation is just wrong?
>Or otherwise where can I find a working example?
>
>Thanks,
>Gereon
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Glen Stampoultzis
gstamp@iinet.net.au
http://members.iinet.net.au/~gstamp/glen/
Re: Persistent properties
Posted by Gereon Fassbender <gf...@startext.de>.
Hi Richard, hi Simon,
thanks for your answers! It makes clear when event firing is necessary.
It is obvious that you have a deeper understanding of the enhancing process.
Maybe you can also answer another question I wrote in the thread "OGNL and
Enhancing Classes problems" some days ago:
> to read or update the property. It is also valid to just implement one
> of the two accessors. The enhanced subclass will always include both a
> read and a write accessor.
I have a problem with exactly this part of the documentation. I defined a
property in the .jwc and implemented the get-method. But I get an error that
the component can't be enhanced because the read method is implemented.
Is it possible that this excerpt of the documentation is just wrong?
Or otherwise where can I find a working example?
Thanks,
Gereon
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Persistent properties
Posted by Simon Raveh <si...@nominum.com>.
Richard Perfect wrote:
>Hi Gereon,
>
>The different sections are because one section is talking about
>"automatic" properties and one section is talking about "manual"
>properties. It is possible to simply declare a persistent property in
>the page specification, use the property in the html template and not
>include anything in the Page java class.
>
>What's happening here is that Tapestry doesn't use *your* page class,
>it extends it (creates a new class on the fly at runtime) and adds
>extra getters/setters for the page persistent properties.
>
>But if you do want to write your own getters and setters (because
>other methods in your class need to call them) then you must also
>include the line about fireObservedChange() because otherwise Tapestry
>won't get to hear about any changes to the property.
>
>
If you need to use the properties in your class you can add abstract
setters and getters and Tapestry will override them and supply the
implementation.
Simon
>GF> So in my understanding you just have to declare the property with
>GF> persistent="yes". Is this right? Does this also work for changes in nested
>GF> objects?
>
>You need to...
> * declare the property with persistent="yes"
> * If you want your own setter method it needs to include the line
> about fireObservedChange()
> * If you want to use mutable/nested objects then anytime they change
> something also needs to signal the fireObservedChange() - see the
> previous emails.
>
> - Richard.
>
>
>Thursday, November 20, 2003, 3:49:09 AM, you wrote:
>
>GF> Hi,
>
>GF> I'm a bit confused about that. There are two sections about persistent
>GF> properties in the documentation:
>GF> Persistent Page Properties
>GF> and
>GF> Implementing Persistent Page Properties Manually
>
>GF> In the first it is said that you just have do declare the property persistent.
>GF> The second section notes the call of fireObservedChange() but also:
>GF> "There is very little reason to implement persistent page properties manually."
>
>GF> So in my understanding you just have to declare the property with
>GF> persistent="yes". Is this right? Does this also work for changes in nested
>GF> objects?
>
>GF> Thanks,
>GF> Gereon
>
>
>
>
>>>Hi Glen,
>>>
>>>I'm pretty new to Tapestry so no doubt the 'old-weavers' will correct
>>>me but since you're near my timezone and they're all asleep
>>>at the moment here goes.
>>>
>>>If you change the value of a persistant property then you are expected
>>>to signal this change to the framework with the following pattern;
>>>
>>>public void setPersonID(Long personID) {
>>> this.personID = personID;
>>> Tapestry.fireObservedChange(this, "personID", personID);
>>>}
>>>
>>>If by mutable property you are talking about the Person object and not
>>>just something like a person ID then you probably still have to do the
>>>same sort of thing.
>>>
>>>
>>>public void setPerson(Person person) {
>>> this.person = person;
>>> Tapestry.fireObservedChange(this, "person", person);
>>>}
>>>
>>>public void someOtherMethod() {
>>> person.setName("Joe Bloggs");
>>> // now signal the change with either
>>> setPerson(this.person);
>>>
>>> // Or...
>>> Tapestry.fireObservedChange(this, "person", person);
>>>}
>>>
>>>To be fair to the framework, it has to have someone tell it that
>>>there's been a change because a persistant property gets stored off in
>>>the HttpSession for all sorts of session and fail-over reasons.
>>>
>>>I suspect you're looking for an automatic way to deal with these
>>>internal changes in which case you would probably need to put the
>>>fireObservedChange() line into everyone of your mutable object's
>>>setters. Which may or may not be a good thing depending on how often
>>>updates are done and how expensive session persistence is.
>>>
>>>Hope this helps, ...surprised you're not watching Australian Idol...
>>>
>>> - Richard.
>>>
>>>
>>>
>>>
>>>
>>>Wednesday, November 19, 2003, 9:18:21 PM, you wrote:
>>>
>>>
>>>GS> I just spend most of the day getting a deeper understanding of persistent
>>>GS> properties.
>>>
>>>GS> What I discovered:
>>>
>>>GS> 1. Persistent properties don't get persisted unless they are marked as
>>>GS> changed. This means that mutable objects that change their internal
>>>
>>>
>GF> state
>
>
>>>GS> don't get persisted (at least not by default) because hiberate doesn't
>>>GS> record them as having changed.
>>>GS> 2. Properties always get initialized before their persistent state is
>>>GS> restored (or not restored). This isn't a big deal but can be a bit
>>>GS> inefficient especially if your property initialization is doing some
>>>
>>>
>GF> heavy
>
>
>>>GS> work.
>>>
>>>GS> Now. As to point number 1. Is there any way for me to indicate that the
>>>GS> internal state of my mutable property has changed? (I'm using the
>>>
>>>
>GF> standard
>
>
>>>GS> property-specification mechanism here).
>>>
>>>GS> Regards,
>>>
>>>
>>>GS> Glen Stampoultzis
>>>GS> gstamp@iinet.net.au
>>>GS> http://members.iinet.net.au/~gstamp/glen/
>>>
>>>
>>>GS> ---------------------------------------------------------------------
>>>GS> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>>>GS> 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
>>>
>>>
>>>
>>>
>
>
>GF> ---------------------------------------------------------------------
>GF> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>GF> 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