Frank Buhr <buhr@kogs1.informatik.uni-hamburg.de> writes:
Hi,
after doing some experiments with Zope I'm still missing an important feature:
How can I easily keep state information over several HTTP-Requests?
The abstraction that provides this is called "session" for instance in the Java Servlet API http://java.sun.com/products/servlet/2.1/html/api-reference.fm.html#945 JS-sessions provide an abstraction from cookie-mechanisms or URL encoding.
Netscapes server side javascript provides similar things. There are some choices for the implementation of sessions: keeping state information on the server (the client only references an ID) or on the client (all values are stored on the client), using cookies, URL encoding or hidden form elements.
I found some Classes in the Zope sources where there is already state information maintained by cookies (TreeTag and ZRDB.DA) This seems to be equivalent to the combination "data on the client, use cookies" from above.
I very much like the idea of separating the service of "state keeping" from the concrete implementation (which might even be chosen dynamically according to browser capabilities or user preferences ("no cookies -> use URL encoding")
Did I overlook something or is there really no session _abstraction_ in Zope?
You are correct, there is no low level session abstraction in Zope. This problem is much thornier than it sounds. Attempting to have a both useable and flexable session toolkit has show to us to be a difficult concept that requires a lot of thought. What are generally called 'sessions' is actually a smaller piece of a much larger puzzle we call 'membership'. More than just a private namespace for a series of HTTP transactions, membership is more of a concept of 'meta-sessions', keeping state between a series of sessions. There are, actually, only a small number of scenarios where construction and destruction of 'sessions' is useful unless the information on the user of that sessions is kept for later sessions. Everyone and their brother has a gazzillion custom requirements they need satified in this very vague (and ill-defined by the JS standard) area we call membership. The actualy 'session' part (which we use a cookie to solve) is one of the easiest pieces of the puzzle. Although many other toolkits have the ability to create an abstraction they call 'session' it is hard to find one that handles membership in a usable and flexable fasion (rumor has it WebObjects has a rather nice model in this regard, of course you have to drop some TALL cash to get it). We want our system to be able to satisfy most requirements, and be able to be molded without breaking any of it to fit all the rest. For example, membership should be flexible enough to store membership information in an SQL database, but it should not be required. So, that aside, I can tell you that this is a deep problem we are thinking about actively here at DC in various top secret projects, and we plan on solving in the usual ultra cool Zope Zen way.
(At first sight the feature now called "versions" seemed to do something similar but this was only the first sight.)
A Session (in my definition) should provide a private namespace for exactly one user (or web client). It should have an optional timeout in order to destroy it if the user is inactive.
Ah there lies the rub. 'exactly one user' is not a concept currently in Zope. It is possible for me to create users called 'michel' at various and disjoined areas of Zope. This is a wildly usable feature of Zope. Creating 'members' is a higher level concept than this, members should be singular, there should be no two 'Michel' members in the same 'membership'. Members should have an area that is 'theirs' (like the UNIX concept of a home directory). etc. etc. It gets sticky and easy to paint oneself in a corner.
Has anyone build a nice Zope product which does this?
I believe there is a product somewhere out there that lets you manipulate cookies in the browser to store some small amount of state (something like 4K) on the client. I believe it was called CookieCutter. This could be useful for your short term goals. Perhaps the author could chime in?
May be sessions could be integrated into the object database (by declaring objects to have a special scope and extent)?
We generally avoid putting HTTP specific (or even Zope specific) feature in the database, this grossly violates our componentized model. The ZODB should (and is) be useful for a variety of applications completely unrelated to Zope or the web. In either case, the database is pretty transparent and low level at Zope's python API layer, so the problem could be easily solved without bringing any thought about the database into it. -Michel
Frank
_______________________________________________ Zope maillist - Zope@zope.org http://www.zope.org/mailman/listinfo/zope
(For developer-specific issues, use the companion list, zope-dev@zope.org - http://www.zope.org/mailman/listinfo/zope-dev )