Lutz, You raise some very interesting points. I've replied to some of the other posters regarding the reasons I was trying to minimise session use, though taking their replies on board and your own email I think the best course of action is to proceed with using the session state and just minimising the amount of data held. Thanks for your contributions.
Regards, Jim. -----Original Message----- From: Lutz Hühnken [mailto:lh.tapestry.l...@googlemail.com] Sent: 06 January 2010 15:26 To: Tapestry users Subject: Re: Persisting state without HTTP Session I see. There wouldn't be much handling, though, one could probably implement a "cookie" persistence strategy, so that you could use the @Persist annotation. Doesn't that even exist already? The thing you are in favor of, using post.. there'll be some disadvantages. I assume you won't be using redirect-after-post much, if you don't want to keep state on the server side. You would have to disable that, as it is the default in Tapestry. I could imagine having a central dispatcher... every post goes to that central dispatcher, the page to be rendered would be one of the parameters. The other parameters would constitute the context for that page. That would be kept track of with hidden form fields. Might be possible, but not a nice solution. No bookmarks, possibly no navigation with browser back - forward buttons.. You could write your context into a database after request processing, and read it on the next request. Of course that would be exactly the same as using a session (in fact, you can configure most servers to store the session in a database). Only slower (than in-memory sessions). Well, now we know why people came up with the session concept. It is actually quite a good approach. What was the reason again you don't want to use it? On Wed, Jan 6, 2010 at 3:04 PM, Jim O'Callaghan <jc1000...@yahoo.co.uk> wrote: > Lutz, > > Thanks for the response - Cookies would be a last resort - I don't want to be > managing cookies and also feel it makes the app more breakable (fundamental > state could be broken with browser security settings). What I'm after is > something akin to PageActivationContext but that passes the relevant > object(s) using Request parameters rather than the querystring / url - thanks. > > Regards, > Jim. > > -----Original Message----- > From: Lutz Hühnken [mailto:lh.tapestry.l...@googlemail.com] > Sent: 06 January 2010 13:50 > To: Tapestry users > Subject: Re: Persisting state without HTTP Session > > > Cookies come to mind, would that be an option? > > > On Wed, Jan 6, 2010 at 2:16 PM, Jim O'Callaghan <jc1000...@yahoo.co.uk> wrote: >> Hi, >> >> Can anyone advise on the preferred way of persisting state between pages >> without using HTTP Session? PageActivationContext using Object[] looks >> promising but I don't want long urls (from serialized objects) and there is >> more data to share than a defined number of keys - I'm looking for something >> that uses POST params ...? Thanks. >> >> Regards, >> Jim. >> -- altocon GmbH http://www.altocon.de/ Software Development, Consulting Hamburg, Germany --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
