Pavlos Christoforou wrote
Here lies the major difference between FSSession and SQLSession. FSSession does not insert the session object in the REQUEST object. It loads the session info into temporary variables in the object. Is there a reason to insert the session object in the REQUEST variable? I can change it if there is a good reason.
I'm not sure I understand what you mean by 'loads the session values into 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.
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.
Query: should it also support __getattr__ ? I've resisted it so far as I don't think so. If users ask for it then we can add it, but I will agree it is not really neccessary.
I've had (I think) two requests for it. The other reason for not adding it is that if people get comfortable using it, they then get bitten by the whole SESSION['a-b-c'] != SESSION.a-b-c (a-b-c is not a valid python variable name).
I think one useful method is one that returns a URL including the SessionUID if client does not support cookies or the URL if it does (BTW what is the best way of detecting whether the client supports cookies?) Here is the implementation in FSSession:
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. Anthony -- Anthony Baxter <anthony@interlink.com.au> It's never too late to have a happy childhood.
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
participants (2)
-
Anthony Baxter -
Pavlos Christoforou