On Thu, Apr 3, 2008 at 5:28 AM, Andy Blower <[EMAIL PROTECTED]> wrote:
>
> I have encountered a similar issue, and the use of onPrepare() doesn't make
> sense to me. Surely there's no point persisting any fields and then
> resetting in onPrepare() is there? May as well just remove the @Persist.
>
> There must be something I'm missing here.. can anyone fill me in?

I believe the issue in this case isn't the @Persist so much as the
initialization of the user object in the page.
private User _user = new User(); <-- Default object for when the page loads

Your pages are pooled so when your page is pulled from the page pool
(or when it's put back I don't recall) it initializes all of it's
properties using the defaults that you set when the object was
constructed. You can make changes to those references, but when the
page loads up again they will be reset. When you initialize a page
property with an object that is used in a form, the properties of that
object are going to be updated when the form is submitted. The next
time that page object is pulled from the pool it's going to get that
modified User object and it's pre-populated values. @Persist limits
the objects storage to the session (or client or whatever extension
you've created) but the class property initialization will be shared
across all your sessions.

Try breaking into your debugger in the getUser() method and checking
out your page object. It has a bunch of fields added to it, including
_$user_default.

Whether or not you need to @Persist the User at all is another
question entirely... I much prefer to initialize the user from the
database on each page load and use the onPassivate event to get the
stored id into the context.

Hopefully some of that is intelligible...
Josh

>
>
>
> Howard Lewis Ship wrote:
> >
> > How about an onPrepare() event handler method to reset the _user field
> > to a new User instance?
> >
> > On Jan 18, 2008 8:44 AM, Hugo Palma <[EMAIL PROTECTED]> wrote:
> >> Imagine the following use case:
> >>
> >> A page to register a new user. I have a User class so i'm all set.
> >> The page class looks something like:
> >>
> >> @Meta("tapestry.persistence-strategy=flash") // because of the
> >> validation tracker thing
> >> public class Register {
> >> @Persist
> >> private User _user = new User();
> >>
> >> public User getUser() {
> >>         return _user;
> >>     }
> >>
> >>     public void setUser(User user) {
> >>         _user = user;
> >>     }
> >> }
> >>
> >>
> >> I'm not using the BeanEditForm component so my template just has a
> >> couple of TextField components with it's value binded to the user bean
> >> properties.
> >> So, now the problem. Because of the way property persistence works, the
> >> actual reference to the user property is kept, so instead of the
> >> property being reset to a brand new instance it's given the kept
> >> reference.
> >> This means that every time that i navigate to the register page the form
> >> will have the values from the last time the form was submitted.
> >>
> >> I guess a workaround would be on every place where i navigate to this
> >> page, to reset the user property before navigating to it. This isn't a
> >> very good solution design wise and doesn't solve the problem when
> >> someone accesses the page directly from it's url.
> >>
> >> So, how are you guys implementing such use case ?
> >>
> >> Thanks
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >
> >
> >
> > --
> > Howard M. Lewis Ship
> >
> > Creator Apache Tapestry and Apache HiveMind
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
>
> --
> View this message in context: 
> http://www.nabble.com/T5%3A-Strategy-for-pages-that-edit-beans-tp14957154p16467445.html
> Sent from the Tapestry - User mailing list archive at Nabble.com.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>



-- 
--
TheDailyTube.com. Sign up and get the best new videos on the internet
delivered fresh to your inbox.

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to