On Tue, 2003-05-27 at 11:53, Edward Pollard wrote:
Sometimes I feel really bad writing to the list for help. It's when I have very simple, very basic questions. I'm sure that the answer is somewhere, but I've not been able to find it.
The likeliest place to find information about sessions in in the 2.6 edition of the Zope Book at http://www.zope.org/Documentation/Books/ZopeBook/2_6Edition/Sessions.stx
I'm having a thought that each of my Zope projects that uses sessions should use individual session containers. I had some problems when one of our student developers and I both shared the same variable names. Quite hilarious.
Session data containers contain session data objects, each of which should be unique for a particular browser (user). It's true that each developer will share the same session namespace for a given user, but you don't need to limit yourself to storing string-valued key-value pairs in the top-level namespace of the session data object. For example, instead of: context.REQUEST.SESSION['avariable'] = 'avalue' ... you can do something like this: my_app_namespace = context.REQUEST.SESSION.get('my_app', {}) my_app_namespace['avaraible'] = 'avalue' context.REQUEST.SESSION.set('my_app', my_app_namespace) In this case you are storing a dictionary named 'my_app' in the session which (as long as no other developer uses 'my_app' as a top-level session key) can be private to your application. Read the section entitled "Mutable Data Stored Within Session Objects" in the Zope Book sessions chapter to understand the 3rd line of the above example.
However, it seems to be conventional wisdom to store session data containers in temporary folders, as the default session data container is. This of course goes away on a restart.
Is there anyway to get them to stick, as the default session data container does?
I'm afraid I don't understand what this has to do with namespace conflicts... but you can create a session data container in your "main" ZODB by selecting it from the Add... menu. Then point your session data manager at it. The data will not go away then but it will be much more prone to conflicts and thus perhaps performance problems. This is also detailed in the Zope Book chapter. - C