[Zope-PTK] PTK Resources

[Phillip J. Eby]

At 04:38 AM 4/1/00 +0200, Alexander Limi wrote:
>
>- I want to do a (presumably) very simple thing: I want users with
>propertysheets. Nothing magic, just your average user with a propertysheet
>attached to him, so I can do things like storing the user's birth date as an
>integer connected to the user, and perform dtml operations based on this
>number.

Ty and I just sent Mike P. a snapshot of LoginManager that supports
"SheetProvider" plug-ins for UserSources and LoginManagers.  By
implementing a SheetProvider plugin, you can add arbitrary property sheets
to users, whose data can be stored in literally any kind of database
whatsoever: ZODB, LDAP, SQL, etc.  That's the good news.

The bad news is, there are still a bunch of issues to be worked out before
a finished LoginManager release, AND the SheetProvider class is currently
just an interface - no helper or example code to show how to write one that
really works.  We expect to release a usable LoginManager this coming week,
but it may not have the SheetProvider stuff fully fleshed out.  It will,
however, have tabs on UserSources and LoginManagers where you can add
SheetProvider plugins, although there may not be any available to add.

Ty and I need to spend some more time looking at the current Zope
PropertySheets implementations and interfaces to decide how much of that
framework we want to build in to the SheetProvider library, and how much
should be "left as an exercise for the reader".  There is also the question
of what kinds of property sheets would be useful for us in our own work, as
that will influence what SP's we would write first.  Still another issue is
security and permissions on PropertySheets, and how to spec that
out/control it from the SheetProvider.

The really really good news about all this, is that we have now abstracted
out of UserSource the idea of a "Rack" (one of the patterns I talked about
at the conference in January).  The Rack is a "thing you store things in",
where the things stored do not know or care how they are stored.  Racks
give their contents property sheets using SheetProviders, so the objects'
properties can be stored anywhere, inside or out of the ZODB.  So if your
app needs to talk to legacy systems, you can abstract that right out of the
picture, and migrating between databases has no effect on app-level code:
you just change the rack or replace the sheet providers.  And Racks can be
used for any object collection, not just users.