[Zope-dev] Test request: ZSession - ZPatterns basedsession manager

[Phillip J. Eby]

At 10:51 PM 6/20/00 +0800, mike wrote:
>"Phillip J. Eby" wrote:
>> example.  Think of someone creating a Session subclass called "Shopping
>> Cart", with methods for viewing, checking out, adding/deleting items, etc.
>> Or, if they have many subsystems which want to share the same Session
>> objects, they could do this by having each subsystem use a different
>> propertysheet of the same Session object.
>
>Well, well, well. As for me, beter I've set up a Client abstraction
>which have access to CartManager and store cart_id in the session
>object. Mixing Session and Cart is not a good idea just because Client
>can have several carts, for example. The composition is better than
>inheritance in this case, Phillip :-)

I look at components in terms of "value add".  Your SessionManager's
value-add is that it lets you transparently create an instance of something
which is associated with a cookie and which can be expired whenever it's
idle for greater than a certain period of time.  But the idea of a
"Session" has no real value-add to me; it just makes it possible for a
thing to be managed by the SessionManager.  You could in fact do without
the Session class altogether, and have SessionManager simply set the
lastAccessed attribute directly.  This would actually make SessionManager
more useful, because you could use it with ZClasses that hadn't been
explicitly designed to be session-based, as long as there was an
AttributeProvider for lastAccessed.  And you could drop the SessionSource
class altogether as well, since any RackMountable/DataSkin would be
acceptable as a "Session".

Popular opinion to the contrary, I don't believe that there is such a thing
as a "session" object.  Session objects are a hack, to give you a place to
put session-specific objects' data.  In my opinion, if you can have
session-specific objects, you don't really need a "session" object.  If one
can simply call CurrentCart() or CurrentGame() (where CurrentCart and
CurrentGame are SessionManager specialists) to retrieve a session-specific
shopping cart or gameboard, why have a "session" object?  If I want them
both to use the same cookie, I can certainly do that by setting the
properties on both CurrentGame and CurrentCart.  And there's also no chance
that two session-specific objects from different vendors (such as perhaps
my Games and Carts) will accidentally collide with each others attributes
or sheets in the "session" object, since they're being handled by seperate
specialists.


>> IMHO, the basicSheet stuff you've done, while convenient, encourages
>> developers to take the quick-and-dirty route of just using the Session as a
>> place to store variables - and that throws away a lot of the usefulness of
>> ZPatterns.  For one thing, you've guaranteed that Sessions have to be
>> stored as persistent objects in the ZODB, or at least that the basicSheet
>> has to support arbitrary properties.
>
>But without this stuff people will have to code ZClasses each time they
>want sessions. Hmm... I guess the best way is splitting current session
>class into two - simple Session and LazySession.

Yeah, but to my way of thinking, they *should* be coding them, because if
they're not it means they haven't thought their design through enough to
know what *kind* of session-specific object they're making.  To me, there
is no such thing as a session object, only session-specific objects.

In any case, it's not a big deal to make a session-specific object.  Add a
ZClass, base it on DataSkin, set up a "common instance" property sheet, and
boom, you're done.  Now set your session manager's rack to use it, and
you're in business.