[Zope] User Sessions
John Morton
John Morton <jwm@plain.co.nz>
Thu, 1 Feb 2001 12:01:44 +1300 (NZDT)
On Wed, 31 Jan 2001 00:30:40 -0000 Chris Withers <chrisw@nipltd.com> wrote:
> > state with authenticated users. It's just not as useful because once
> > they're authenticated you'd probably be better off associating the state
> > with their user object.
>
> Wow... I wish Zope supported this. Maybe a proposal for dev.zope.org is in
> order?
>
> How I'd like to see text box widths and top frame preference stored against
> the user, not the domain name/browser... :-S
In principle you could do this by spawning a property sheet off the user
object for each product and storing attributes in that - and I think
that's one of the things that Zpatterns would like to make possible,
however in practice I haven't figured out how to do it the way I'd like to
without making the LoginManager specialist become the customization
specialist for each product.
However, Zpatterns talks about products[1] being able to add property
sheets onto other object without that object 'knowing', so maybe it is
possible, and I haven't figured it out yet (I don't think I'm the only one
who finds the jargon make my head spin). On the other hand, they also talk
about making property sheets act like data managers so you can define data
plugins to handle their individual attributes as being a feature they'll
include in 0.50 or something, so maybe it isn't possible just yet.
I'm looking to solve the customization problem in the interim by having a
given product define a class for their customization data and methods, and
have a specialist in the aquisition path manage the data, keyed to the
name of a given user object[2]. As a site integrator, I can modify the
specialist's data plugins to say something like 'don't get and store the full
name and email address in this object, instead, get them from this global
data specialist over here'. I think this will solve most of my immediate
problems.
John
[1] Applications/frameworks/whatever-the-kids-call-it-today
[2] Or better yet, the user object has a method to return a primary key,
so that user objects can change their login name with ease.