Howard, I totally get the "two request" pattern. A user shouldn't have to decide whether to re-submit their information. Great feature of the framework.
So let's say that the "request scope" I'm referring to would be "browser round-trip scope". As people on the forum have pointed out, combinations of the back button, refreshing, spawning new browser instances (which share session information) all can create chaos for any session-interacting web application. Just seems strange that seasoned web developers who use Tapestry are "baking their own" persistence mechanisms. Some are even making protocol-ish marker-based activation context constructs (/editdoohickeys/d1/keyval1/keyval2/d2/keyval1/keyval2). Sounds like what most of us are requesting is to at least permit the developer to not have to persist their components in the session (something like ServletRequest.setAttribute/getAttribute instead). Now that I've thoroughly beaten it, I'll just let the dead horse decompose for a while until it starts to smell (no Eight Belles reference intended). Joel -----Original Message----- From: Howard Lewis Ship [mailto:[EMAIL PROTECTED] Sent: Saturday, May 03, 2008 5:38 PM To: Tapestry users Subject: Re: T5: Persistence pains On Fri, May 2, 2008 at 6:36 PM, Joel Wiegman <[EMAIL PROTECTED]> wrote: > Josh, > > Thanks for the great suggestions. > > I guess I'm still befuddled as to why a web framework would resist having a "request scope" so dilligently. It's not resistance, it's a different mindset, one that states that URLs should stand on their own in the browser and represent data to be presented to the user (i.e., render page requests) rather than behaviors to execute (the action requests). >From what you describe, your activate event handler method should be able to load whatever additional data is needed and store it in simple component fields: that's your request scope. The fact that Tapestry links action requests to page requests is a separate issue. The goal is that if the user clicks the refresh button (the other annoying thing users do, besides hit the browser back button) that there won't be unexpected side-effects (such as, for instance, re-submitting an order, re-sending an email, etc., etc.). > > The "flash" scope appears to makes some intelligent guesses as to when you want your objects removed from the session, but the back-button-example I listed is one of quite a few reasons why making such guesses is a fools game. As we all know, HTTP is a request-response, stateless protocol, but Tapestry appears to be resisting storing state in one of the most basic constructs available in HTTP... the request. Anyone know why this is? Because we can store it inside ordinary fields instead? > > As you illustrated, I'm sure there are quite a few elaborate ways of dancing around the issue in any application (redundant checking, re-verification, passing "clearThisValue" flags around, etc.). None seem very elegant though (and would probably be associated with "this is why I'm doing this" comments). > > As for your activation context suggestions, those are some neat ideas. I hadn't considered your "marking" suggestion. I'm a little afraid to use it though. I can see a Tapestry pattern evolving from that that yields (String... stuff) as your parameter to your onActivate with a boatload of extravagant logic. > > Anyway, still haven't heard a useful suggestion to get objects into a "request only" scope. If anyone can think of something please post! It would be interesting to see what some of these values are that can only be set inside an action request but must then span into a render request. > > Thanks, > > Joel > > > > > -----Original Message----- > From: [EMAIL PROTECTED] on behalf of Josh Canfield > Sent: Fri 5/2/2008 6:31 PM > To: Tapestry users > Subject: Re: T5: Persistence pains > > 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] > > > > > --------------------------------------------------------------------- > 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]
