Mailing List Archive

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.

> >- 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.

> 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.

OK. I have quite a high-profile site on my hands, and the number of expected
users on the site will be high. I am definitely interested in being part of
the beta testing, as I _really_ need the code for a basic propertysheet to
be tied to a user. I could have programmed my own solution, but I would like
to be able to take advantage of the extra functionality that the PTK
eventually will offer.

So, how about it? What is the projected time frame for basic functionality
like the one described above? I am prepared to tweak the code if necessary,
and contribute as much time and work as I can to get it ready as soon as
possible.

And sorry if I am a bit impatient, our public site will go live in a matter
of weeks, and it would be absolutely brilliant to have this functionality in
place when it does.

Regards,


Alexander Limi