>  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
data
>  structure, maybe by sticking them into an instance of a class that also
>  implements the mapping interface and put that instance in a folder
somewhere
>  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,
have
>  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
session
>  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  -  Zope-Dev@[...].org
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )