So I checked it out... This may be of use to me :-) Question: so once the object is done (ie flashed), will this invalidate/destroy the session if it had to create one? I would be interested in something like this because my app avoids creating a session under "guest" user at all possible costs. If flashing object to session leaves the session alive, I'm afraid I could not use it.
Adam On 3/29/06, Mike Snare <[EMAIL PROTECTED]> wrote: > The only problems with client persistence are that > 1) the object has to be serializeable > 2) it increases the size of the page > 3) URLs get long, since the object has to be sent back and forth. > > A possible alternative might be tapestry-flash > (http://howardlewisship.com/tapestry-javaforge/tapestry-flash/) which > stores the object in the session only until it is used, then discards > it. It may not work if the page needs to be re-rendered due to > validation issues, but it might be worth a look. Never used it tho... > > If your object is expected to be small then client-side persistence > should be fine. If (as you asked) the object has 20+ fields it may > get a bit cumbersome. > > -Mike > > On 3/29/06, Andreas Andreou <[EMAIL PROTECTED]> wrote: > > Try client persistance. > > persist="client:page" instead of persist="session" > > > > GbT wrote: > > > > > Ok, I understand, but it seems code redundant for me to write three > > > property for the same object only to submit values back... Suppose I > > > have 20 fields for example to edit... I have to declare every single > > > field in the Edit page... and assign every form field to them.... > > > Isn't it possible to do something similar to WebObjects component > > > based things... passing the object directly? > > > > > > Il giorno 29/mar/06, alle ore 16:00, Mike Snare ha scritto: > > > > > >> The problem with just making it persistent is that you now have to > > >> handle the case where the user gets to the edit page via a path other > > >> than the intended one (probably clicking on an article title or > > >> something). > > >> > > >> Normally, you could just check to whether the article or id was null > > >> or empty in the validate method, then redirect to an appropriate page. > > >> Now you can't do that. During a particular session the article or id > > >> will never be null once the page is correctly accessed once. This may > > >> not be desired. > > >> > > >> Imagine the user uses your edit page to edit an article then visits > > >> several other pages. If he then uses the drop-down menu for the back > > >> button to get back to the edit page he'll see the edit page for > > >> whatever article he last edited. > > >> > > >> Just a thought, > > >> -Mike > > >> > > >> --------------------------------------------------------------------- > > >> 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]
