No, I get that there's an issue here ... I think conversational scope would be helpful. In addition, we need more smarts about what gets stored persistently, something like ValueEncoder but for persisted values; simple values (String, int, etc.) are find, but we need to recognize complex objects, such as Hibernate entities, and store just the entity id in the session, or as client-side data.
On Mon, May 5, 2008 at 6:02 AM, Joel Wiegman <[EMAIL PROTECTED]> wrote: > 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] > > -- Howard M. Lewis Ship Creator Apache Tapestry and Apache HiveMind --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
