His problem is that his properties are not persisting, neh? So he
needs to implement some form of persistence. If he doesn't, some of his
properties may "hang around" in the page because they're never
re-initialized, but then you're basically racing the garbage collector (and
any other user who might check out the same page).
So far as I know, if you're not actively persisting your properties
(setting and using the persist flag for example), then the fact that a
property stays set between interactions with the client is nothing more than
an artifact of a development environment where you're the only one using a
given page instance. In production, where somebody else may check out that
page instance and set its concrete properties, you can't count on things you
"set" in the page object still being there the next time you happen to
request it.
For that matter, you might not even get back the same page object
instance, all Tapestry guarantees is that if you ask for a "Login" page you
get an instance of that page class. It doesn't guarantee that a given
session gets the *same* instance back time after tim.
--- Pat
> -----Original Message-----
> From: Robert Zeigler [mailto:[EMAIL PROTECTED]
> Sent: Thursday, July 21, 2005 8:46 PM
> To: Tapestry users
> Subject: Re: Custom class persistent objects are not persistent
>
> Richard is right. He doesn't need the abstract accessors. In fact, he
> doesn't need anything in the .java/.class file for his properties.
> As he pointed out, he's only using the properties in the .page file. As
> long as there is no need to access the property in your java code,
> there's no need to define the abstract accessors.
>
> That said, I'm using 3.0.3, and have no problems at all with persistent
> properties.
>
> Perhaps you could show us a bit more of your .page file? A look at the
> .java wouldn't hurt, either.
>
> Robert
> Patrick Casey wrote:
> > For better or for worse, Tapestry "prefers" to deal with abstract
> > properties to it can auto-magically enhance your page class. Just as you
> > propose, an abstract property is a property for which you have abstract
> > getters and setters, but not implementation.
> >
> > For those cases where you need to implement concrete properties,
> > you're left with two alternatives:
> >
> > 1) Roll your own persistence layer (my preferred approach).
> > 2) Use Tapestry.fireObservedChange(<Page>, <Property>) in the
> > setter for each concrete property (do a search through the doc for
> details)
> > to manually force persistence. Note though that I think this approach is
> > deprecated in 4.0.
> >
> > --- Pat
> >
> > PS No, I don't like this particular implementation either, but it is
> > what it is.
> >
> >
> >>-----Original Message-----
> >>From: Richard V. [mailto:[EMAIL PROTECTED]
> >>Sent: Thursday, July 21, 2005 7:54 PM
> >>To: [email protected]
> >>Subject: RE: Custom class persistent objects are not persistent
> >>
> >>What do you mean by abstract properties? Do you mean to define the
> >>javabeans
> >>functions as abstracts in the page class? Something like:
> >>
> >>public abstract String getMyValue(); public abstract void
> >>setMyValue(String
> >>value);
> >>
> >>But these functions are related to accessing the properties in the page
> >>class implementation declared from the .page file. I only make use of
> >>"myValue" property from within the .page file, so I don't need those
> >>abstract functions from above.
> >>
> >>Richard
> >>
> >>
> >>
> >>>From: "Patrick Casey" <[EMAIL PROTECTED]>
> >>>Reply-To: "Tapestry users" <[email protected]>
> >>>To: "'Tapestry users'" <[email protected]>
> >>>Subject: RE: Custom class persistent objects are not persistent
> >>>Date: Thu, 21 Jul 2005 18:56:55 -0700
> >>>
> >>>
> >>> If memory serves, the "persistent=yes" tag only works on abstract
> >>>properties. Concrete properties like you use are going to require you
> >>>persist them yourself.
> >>>
> >>> --- Pat
> >>>
> >>>
> >>>>-----Original Message-----
> >>>>From: Richard V. [mailto:[EMAIL PROTECTED]
> >>>>Sent: Thursday, July 21, 2005 6:48 PM
> >>>>To: [email protected]
> >>>>Subject: Custom class persistent objects are not persistent
> >>>>
> >>>>Hello everyone,
> >>>>
> >>>>I have a problem with Tapestry 3.0.3 in regard to persistent
> >>
> >>properties
> >>
> >>>in
> >>>
> >>>>a
> >>>>page. I noticed that for java simple class objects such as String,
> >>>>Integer,
> >>>>Boolean, etc. used as persistent properties in a page behave as
> >>>
> >>>expected;
> >>>
> >>>>i.e. they are part of the http session. However, this does not seem to
> >>>>hold
> >>>>if you use complex classes (i.e. created by composition of other
> >>
> >>simple
> >>
> >>>>classes). For example the following class:
> >>>>
> >>>>public class VString implements Serializable {
> >>>> String value = null;
> >>>>
> >>>> public VString() {}
> >>>> public VString(String str) {
> >>>> setValue(str);
> >>>> }
> >>>> public void setValue(String str) {
> >>>> value = new String(str);
> >>>> }
> >>>> public String getValue() {
> >>>> return value;
> >>>> }
> >>>>}
> >>>>
> >>>>
> >>>>And to use it in a page, I will define the following:
> >>>>
> >>>><property-specification name="myValue" persistent="yes" type="VString"
> >>>>initial-value="new VString('default')"/>
> >>>>
> >>>><component id="inputValue" type="TextField">
> >>>> <binding name="value" expression="myValue.value"/>
> >>>></component>
> >>>>
> >>>>The property myValue will not persist and resets to "default" on the
> >>>
> >>>next
> >>>
> >>>>refresh of the page. However, it will stay if you change the type from
> >>>>VString to String.
> >>>>So, my question would be: is this normal behavior from Tapestry or am
> >>
> >>I
> >>
> >>>>missing something to get this work?
> >>>>
> >>>>Many thanks in advanced.
> >>>>
> >>>>Richard
> >>>>
> >>>>
> >>>>
> >>>>---------------------------------------------------------------------
> >>>>To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>>>For additional commands, e-mail: [EMAIL PROTECTED]
> >>>
> >>>
> >>>
> >>>---------------------------------------------------------------------
> >>>To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>>For additional commands, e-mail: [EMAIL PROTECTED]
> >>>
> >>
> >>
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
