On Wed, 9 Feb 2000, Kevin Dangoor wrote:
> I've moved this to the PTK list to protect the innocents over on the zope
> list :)
Thanks for bringing it to my attention... I scan the zope list once a
week for ZWN, and that's about it. :-/
> I assume you're talking about the Folder sort of propertysheet and the
> ZClass version of propertysheets. Having done a lot of work with ZClasses,
> I'm inclined for propertysheets for users to be ZClass-like. In other words,
> all users have properties that are defined at the top level with default
> values. I don't think I'd want to go to Joe User and add a property "foo" to
> that one user. I'd be more likely to add a feature that I want to
> enable/disable for everyone initially and would want a property added to
> everyone.
Yes, this is most certainly true.
> That seems like it may be somewhat of a pain to implement, because users
> aren't ZClasses... but, you've looked at the source more than I have :)
Holy cow, I'm just now trying to figure out how ZClasses use
propertysheets. Looks like it creates a new _class_ for each ZClass's
propertysheets definition, so that it can potentially inherit the property
definitions from the ZClass this ZClass is subclassing. Then, when the
ZClass in instantiated, the instance gets instances of the ZClass's
propertysheets class. I think. Who can tell?
Anyway, there is obviously way more complexity here than we need, or
can probably even adapt. Besides that, if we tried to use the ZClass
code, any day now we'd find that Jim had completely rewritten it on his
Palm when he got bored waiting in line for an ATM.
Looking at OFS/PropertySheets, I think there is support for the kinds
of things we're trying to do. FixedSchema SEEMS to accept a 'template'
propertysheet, and doesn't allow you to add additional properties. So,
you (the LoginManager installer) build your PropertySheets on the
LoginManager object somehow, and it (meaning it or one of the objects it
manages) uses those sheets as the model for the sheets on the user
object. It loads the user's values from the UserSource (?) into the
user's propertysheets, et voila. We're done, right? ;-)
Oh, we have to extend FixedSchema to tell the UserStore when
properties change. It all seems straightforward-ish... Now that I have
the LoginManager code, I'll see if I can implement it.
> Are users going to be Folderish? Or, will people just make a separate Folder
> for storing their personal stuff. I'm thinking that I would like to store a
> user's shopping cart/wish list in their own area, as well as some kind of
> order summary objects to store their order history...
I think it would be best if users were not Folderish. The desire is
that, if you put enough work into it, no part of a user (including
properties) _have_ to be stored in the ZODB. This is because users are
often both the most volatile and common objects. A bad combination for
the ZODB...
Anyway, if we make users Folderish, then what we're really doing is
trying to stuff arbitrary object trees in arbitrary databases. I think
that if you need users to have a folder associated with them, you should
handle that yourself.
> Kevin
--
Mike Pelletier email: mike@digicool.com
Mild mannered software developer icq: 7127228
by day, super villain by night. phone: 519-884-2434