On Wed, 5 Jan 2000, Anthony Baxter wrote:
temporary variables in the object'. The rationale behind having REQUEST.SESSION was to make it behave in a way similar to RESPONSE. I explicitly did _not_ want to have session variables automatically looked up, or stored - this seemed to me to be an error prone way to go. I also dislike things that stomp all over my global namespace, and pulling all session values out seemed too much like 'from foo import *' to me.
There is no global namespace pollution really. FSSession stores all session info in a mapping object that does not participate in Zope's transaction machinery. When FSSession is initially called the mapping object is populated with the session info, which can be accessed like: <dtml-var "FSSession['info']">. At the end of the request, if any session data were modified/added then the mapping object is marshalled back on the filesystem. Thus all the session info is only visible through the FSSession object and its methods, and changes are stored only once, at the end of a succesful request. The reason I chose this approach over the SQLSession one is that this allows one to get away with having to call the Session management object before it can be used. Even though FSSession now requires one to call FSSession initially, the mapping object methods can be rewritten to check whether the session info has been loaded or not and act accordingly, thus eliminating the need to call the session object first.
SESSION API: SESSION.getName() - returns the session id of the current session.
Ok I will add it. Right now the SessionUID is inserted in the REQUEST object.
I could add that as well, I guess - but I prefer having all of the session values inside REQUEST.SESSION.
Agreed. All the session values are in FSSession but the Session ID is used often enough and having it in the REQUEST object makes things more convenient. I prefer typing: <dtml-var SessionUID> rather than <dtl-var "FSSession['SessionUID']">. No big deal really. I can remove it if you think is unneccessary.
Hm - I've thought about this, but haven't come up with an authoritative (if that's the right term) way to deal with it. One way I've thought to do it is to make the first form submit have a hidden field called something like '_this_form_should_send_in_a_cookie_called_foo', then check the next page for a cookie called 'foo'. If it's not there, stuff 'foo' into the URL.
I'd like to avoid putting the session in the URL by default, tho.
This is mainly a convenience function (PHP session manager includes something similar I believe). It was requested by a Zopista so I added it. It is not really meant to be used as the default method. Most of the times the programer will decide explicitly how to pass the sessionID around. Mashal vs cPickle ... My tests show that for a fairly complex structure marshal is roughly 2x faster than cPickle in dumping objects and 3x in loading objects. I figured in the rare cases that one needs to store more complex structures than marshal supports, one can use a simple external method that takes an object as an argument and returns the pickled string. And I will agree with you that an easy way to inspect session info is nice. My approach is to include a simple utility with the distribution that can pretty print session info from the command line. I wouldn't want to use a less efficient internal represenation though. What do you think? Pavlos