> > But all of these ponderings are kind of moot, because session
> > data can be
> > arbitrarily large (session data on the order of a megabyte
> > will probably not
> > be uncommon), so the data can't realistically be embedded in the token
> > anyway.
> Agreed, in-URL session data is not a universal solution. Im definitely
> interested in implementing this as an *alternative* SessionManager, and I
> aware of these limitations.
Hmmm... I think I see what you're getting at. It may be outside the scope
of session- tracking altogether, although you could probably build something
like this on top of the session tracking machinery. It's not really
session-tracking, it's... snapshot-tracking. You're not really required to
keep any notion of a "session" to do what you want to do, it's just a
disconnected series of states that are storable on the client side.
> What about the scenario....
> 1. I have a half full shopping cart (or a half opened tree tag)
> 2. I bookmark that half full cart.
> 3. I fill up the cart, but then change my mind.
> 4. I return to the bookmarked page - do I go to
> A. the half full cart from step 2, or
> B. the full cart from step 3?
> 5. I return to the bookmarked page 12 months later - do I go to
> C. the half full cart from step 2, or
> D. the full cart from step 3, or
> E. an empty cart, because the session cache had been purged.
> I guess B D and E all make sense in the context of a shopping cart (feel
> free to disagree; Im not too hot on shopping cart usability)
Well, in traditional session-tracking, the answers are most likely B and E.
If we could get even to there, I'd be happy... :-)
> I'm currently using a fremework built around in-url data to maintain the
> state of a sophisticated View (as in an M-V-C idiom). Options A and C are
> essential, since users need the ability to bookmark a view and return to
> However most views are transient, just intermediate views on the way to
> view that they want to keep. I dont have the storage on the server to
> indefinitely record every view that has ever been seen, however the server
> has no way of knowing which views have been bookmarked. The only option is
> to store all view state on the client, inside the bookmarked url.
> Being able to use a SessionManager to integrate a (rewritten) tree tag
> my rich views is appealing.
I'd encourage you to put more thought in to how something like your
snapshot-tracking could be aided by the session-tracking components outlined
in the wiki...
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -