Hi Joel,
First,
> PLEASE PLEASE don't interpret this as Tapestry-bashing.
Yikes, hopefully the troll-bashing hasn't made people afraid to ask
tough questions for fear of being labeled troll.
Anyway, back you your question. So, when you render a page you want
some state that was used to render that page to be available the next
time you render the page. You don't want that state hanging around in
the session if the user leaves that page?
> 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).
@Persist("client") is better than @Persist("session") when you're
either unable or choosing to not use sessions. It also prevents you
from having to deal with expired sessions. If the user goes away and
comes back an hour later, the page should still work.
> 4) Activation context magic ... (hint: composite
> primary keys are almost unusable).
Can you be more specific about your trouble with composite keys?
> Also, if your page uses more than
> one dynamically-sized collection of objects, then you're out of luck.
I've used markers for cases where I was stowing different types of
context in the url.
http://localhost/m1/one/two/m2/hello/world
Somewhere there is code floating around for cookie based persistence.
That gets it onto the client without putting it in the url. If you're
concerned about the same session being opened in two browsers, there
is also an implementation of "conversation" in the latest jumpstart
that you could take a look at...
Of course, these are tied to page and component. If you want a cookie
based Application State Object that you can pass between pages, I
think you'll have to write that one up.
If you really want to make sure that you aren't using data intended
for a different instance of the page, you could tie the object in the
cookie to an activation context value. If they don't match assume that
you're in a wonky state and clear it out.
Josh
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]
>
>
--
--
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]
