I generally consider flash persistence as a way to get an object from the action request to the render request...
If you're going to set it in the render request you should consider adding code that validates that your data and context match up. You could, for instance, also flash persist your id and check it against the id from the context. If they don't match then null your other properties. > While some may argue that this is "just poor design", what if the fields > I initialize varies by product? I'd get a "merging" of the two products > on the screen depending on what was persisted first. Storing these things in your component smells funny... but I don't know your app. If someone is coming to the page for the first time you want an empty object, if they are posting an update to the form then Tapestry is going to populate the values. If you are navigating within the page using pagelinks, but it's a form then I'd consider posting the form instead... Josh On Fri, May 2, 2008 at 2:39 PM, Joel Wiegman <[EMAIL PROTECTED]> wrote: > Sure Howard. > > Quite simply, "the back button". When loading a page with an activation > context, say: > > http://myapp.com/editproduct/20 (where 20 is a product ID) > > I'll initialize some flash-persistable values on the page from the > Product whose ID is 20. > > Now if the user clicks on the Back button and goes to a link that reuses > the same screen but without a context, say: > > http://myapp.com/editproduct/ (let's say this page "should" blank out > the screen so the user can enter a new product) > > Most of my flash-persistable values (from Product 20) will still be on > the screen. > > While some may argue that this is "just poor design", what if the fields > I initialize varies by product? I'd get a "merging" of the two products > on the screen depending on what was persisted first. > > Are these scenarios valid? > > > > -----Original Message----- > From: Howard Lewis Ship [mailto:[EMAIL PROTECTED] > Sent: Friday, May 02, 2008 5:17 PM > To: Tapestry users > Subject: Re: T5: Persistence pains > > Could you elaborate on why the "flash" persistence strategy is > insufficient for your needs? > > On Fri, May 2, 2008 at 2:00 PM, Joel Wiegman <[EMAIL PROTECTED]> > wrote: > > All, > > > > Maybe I'm missing something here, maybe I'm not, but I'm attempting > > to preserve state JUST BETWEEN REQUESTS and I'm really struggling (I > > know in T5 there's <really> two requests, but for simplicity's sake > > let's just call the round trip from the browser a "request"). > > > > My options are: > > > > 1) @Persist("session") > > - Obviously doesn't work well for just persisting values between > > requests, unless someone has come up with a reliable construct for > > nulling out these values whenever someone leaves the page? > > > > 2) @Persist("flash") > > - This is really only useful for messages and other objects that are > > > reliably referenced once. This is NOT "request-scoped persistence". > > > > 3) @Persist("client") > > - While I thought initially thought that this would solve all my > > woes, instead every link in my application now carries around an huge > > > encoded state variable in the URL. I'm completely missing the > > benefit of this versus just using session persistence (enlightenment > appreciated). > > > > 4) Activation context magic > > - While this does make for clean and nifty URLs, the hassle of > > constructing the identifiers for complex objects and creating the > > contexts for them has not proven "worth it" to me (hint: composite > > primary keys are almost unusable). Also, if your page uses more than > > > one dynamically-sized collection of objects, then you're out of luck. > > > > PLEASE PLEASE don't interpret this as Tapestry-bashing. Tapestry has > > > been a delight to work with compared to previous frameworks I've used. > > I'm just really struggling with how to do something that, IMHO, a web > > > framework should make very simple (request-scoped persistence). > > > > Anyone solve this riddle yet? > > > > Joel > > > > > > --------------------------------------------------------------------- > > 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] > > > --------------------------------------------------------------------- > 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]
