Re: T5: Persistence pains

[Ivan Dubrov]

Right. Most annoying things for us about “session” and “flash” scopes 
was that they don’t work in several tabs. And “client” can’t hold too 
much data.

That’s why we have implemented a new persistence strategy named “flow” 
(inspired by the Spring WebFlow). The idea is that every URL has flow 
key stored in it, and the state is stored in the session under this key. 
The state is versioned (actually, the state is immutable, every change 
to the persistent fields introduces new state). We keep about 10 
previous states, to keep the session from overburdening.

There is still some issues with AJAX calls, though.

The biggest argument to be made for "request scope" state that is 
automatically (or framework assisted developer code) persisted in the 
page vs. the "flash" technique of Tapestry is when considering 
multiple browsers opened by the user with the same session. Every app 
that I've developed, we've had to diligently ensure that nothing other 
than "login" credentials were stored in the session and everything was 
persisted within the request. For T3, our team developed an elaborate 
set of components that made this trivial (including our own 
annotations based support). The fact that Tap 5 gets in the way of 
trying to have a very light session is a little disconcerting. The 
other side-effect of "flash" would be thrashing in a clustered 
environment.

----- Original Message ----- From: "Howard Lewis Ship" <[EMAIL PROTECTED]>
To: "Tapestry users" <users@tapestry.apache.org>
Sent: Saturday, May 03, 2008 5:37 PM
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]




--
WBR,
Ivan S. Dubrov


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]