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]
