> Cool! Note that the session data object implements the mapping interface,
> so you don't really need to pickle up a copy of it. I'd recommend against
> this, although it seems to be working well for you.
Any special reason why I shouldn't pickle apart from the fact that the ZODB
will do it to save the object?
> Instead, to save a session state, I'd just grab the current session data
> object and iterate over its items, grabbing things out of it that are
> interesting to my application. Then I'd copy these things into another
> structure, maybe by sticking them into an instance of a class that also
> implements the mapping interface and put that instance in a folder
> which is related to the currently logged-in user.
Cool, I'll have to look at the mapping interface. I use a "fixed" version of
UserInfoFolder to maintain a folderish object on each person, Im throwing
this into there. Works nicely.
> Then when a user wanted to restore a saved session state, get a list of
> session state objects in his session state folder, present them to him,
> him select one. When he does, copy the items out of it into the current
> session data object.
> The nice thing about this general strategy is that you can work with the
> current session data object in all of your app code that depends on
> state. How the session state is saved and restored (and what the session
> data object values are) is completely independent of the app code.
Yep this is what I like. Im actually thinking this simple ZStore class is a
useful little object for throwing stuff into, if I get mapping working I'll
release the whole 50 lines of code it currently is...
Thanks for your help.
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -