> 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.

  Andy McKay.

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope )

Reply via email to