Hmmm, I'm not sure I understand the total of your problem, and I'm a
bit suspicious that you might be solving the wrong problem here. Here's some
information that *might* help though.

        Tapestry uses page pooling. Every time a user renders a page, if
there's an "old" version of that page in the pool, Tapestry uses the pooled
version instead of a nice new one.

        So if User A loads up Login and fills in some fields, then user B
clicks login, he'll get the fields that are "left over" from User A (like
his UID/Password!).

        There *is* a mechanism to avoid this, and it doesn't require you
make everything persistent. Simply implement the "initialize()" method on
your page classes and use it to set all fields to default values before your
page goes back into the pool.

        The important thing to realize is that the "initialize()" method has
a misleading name (Damn you Howard!). It *does not* run once like a
constructor. Instead it runs every time a page is released to the pool to
reset page state to defaults.

        Hope this helps,

        --- Pat

        PS Tapestry 3.0's persistence model doesn't play well if a given
session has multiple instances of the same page up. In point of fact,
whichever instance of the page that was rendered most recently "wins" and
its properties get persisted. So if you open, for example, two "editDog"
pages in new tabs, then the second editDog will persist and overwrite the
properties from the first one.

> -----Original Message-----
> From: hari ks [mailto:[EMAIL PROTECTED]
> Sent: Monday, August 22, 2005 10:00 AM
> To: Tapestry users
> Subject: RE: Visit object or use persistent="yes" of property-specificaion
> (TIA). Also need tapestry coding standards.
> 
> hi,
>    Our project ran into issue with respect to tapestry
> caching. Developers added lot of instance variables
> causing one user's data coming to another user. We
> needed a quick and permanent fix. Or the guidelines
> need to be followed to get this fixed. (there are more
> than 100 tapestry pages to be fixed, with complicated
> business logic in each page)
> 
> Do you feel, that this would require a code
> restructuring?
> We tried to follow these guidelines to remove certain
> instance variables. (again not all instance variables
> could be converted those gets changed during page
> render phase)
> Please confirm whether this is correct?
> 
> 1. If there is both getter/setter and both directly
> accesses instance variable, then those 2 mothods are
> converted to abstract and property moved to .page file
> 2. If the original property value was initialized to
> some value in class file(class variable
> initialization), initial-value is given to that in
> property-specification(otherwiase, don't give
> initial-value)
> 3. persistent="yes" is given in all cases, because
> getter and setter accessing class variables(original
> code), maintains its state between requests.
> 4. When converting non-abstract getter/setter to
> abstract , make sure you delete class variable
> associated with getter/setter. and make necessary
> changes.
> 
> Thanks,
> Hari.
> 
> --- Patrick Casey <[EMAIL PROTECTED]> wrote:
> 
> >
> >     Can you give an example of what exactly you're
> > getting at here? I'm
> > not sure I'm seeing the concern you're having with
> > the Tapestry approach.
> >
> >     --- Pat
> >
> > > -----Original Message-----
> > > From: hari ks [mailto:[EMAIL PROTECTED]
> > > Sent: Monday, August 22, 2005 1:54 AM
> > > To: Tapestry users
> > > Subject: RE: Visit object or use persistent="yes"
> > of property-specificaion
> > > (TIA). Also need tapestry coding standards.
> > >
> > > Thanks. That clarified many things.
> > > Does that mean Visit object need to always act as
> > > facade to domain objects. For applications that
> > have
> > > pages that keep on growing, how do we manage
> > these.
> > > What is a reference implementation for tapestry?
> > > Can betterpetshop project be taken as refernce?
> > > Or any of the examples that come with tapestry
> > > distribution?
> > > Thanks,
> > > Hari
> > >
> > > --- Patrick Casey <[EMAIL PROTECTED]> wrote:
> > >
> > > >
> > > >         Tapestry persistent properties are linked to a
> > > > specific page, not to
> > > > a session.
> > > >
> > > >         So if you log in on page "Login" and persist
> > > > "currentUser" it won't
> > > > be available on page "welcomeScreen" because
> > it's
> > > > only persisted to the
> > > > Login page.
> > > >
> > > >         An additional limitation is that persistent
> > > > properties aren't
> > > > associated with a specific page instance, but
> > rather
> > > > with a page/session
> > > > combination. Thus if a given session brings up
> > two
> > > > copies of the same page,
> > > > their persistent properties will overwrite one
> > > > another.
> > > >
> > > >         Generally speaking if you want information to
> > have
> > > > global scope e.g.
> > > > be available on more than one page, stash it in
> > the
> > > > visit object (which then
> > > > goes in the session), or put it in the session
> > > > yourself.
> > > >
> > > >         --- Pat
> > > >
> > > > > -----Original Message-----
> > > > > From: hari ks [mailto:[EMAIL PROTECTED]
> > > > > Sent: Monday, August 22, 2005 12:54 AM
> > > > > To: [email protected]
> > > > > Subject: Visit object or use persistent="yes"
> > of
> > > > property-specificaion
> > > > > (TIA). Also need tapestry coding standards.
> > > > >
> > > > > Hi,
> > > > >    In tapestry in action - hangman
> > application, a
> > > > > user's state is stored in Visit object
> > > > > (Game/WordSource are inside Visit). Visit acts
> > as
> > > > > facade for Game & WordSource.
> > > > >    Is this always the way we should code our
> > > > tapestry
> > > > > application.
> > > > > Or can we also use persistent="yes" directly
> > in
> > > > > property-specification of a page to maintain
> > user
> > > > > state for a session.
> > > > >
> > > > > What would be the drawbacks of using
> > > > persistent="yes"
> > > > > for lots of properties in a page.
> > > > >
> > > > > Also I presume eliminating instance variables
> > is
> > > > not
> > > > > completely possible in tapestry page because
> > > > > components like Foreach,ListEdit etc.. would
> > need
> > > > > them.  But new developer starts using instance
> > > > > variables to store user state between request
> > > > causing
> > > > > possible security breach because of caching.
> > Is
> > > > there
> > > > > any coding standards defined for Tapestry
> > > > anywhere?
> > > > > Want to implement the tapestry coding
> > standards in
> > > > our
> > > > > project.
> > > > >
> > > > > Thanks,
> > > > > Hari
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > ____________________________________________________
> > > > > Start your day with Yahoo! - make it your home
> > > > page
> > > > > http://www.yahoo.com/r/hs
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
> ---------------------------------------------------------------------
> > > > > 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]
> > > >
> > > >
> > >
> > >
> > > __________________________________________________
> > > Do You Yahoo!?
> > > Tired of spam?  Yahoo! Mail has the best spam
> > protection around
> > > http://mail.yahoo.com
> > >
> > >
> >
> ---------------------------------------------------------------------
> > > 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]
> >
> >
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
> 
> ---------------------------------------------------------------------
> 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]

Reply via email to