[Zope-PTK] PTK, LoginManager and user maintenance

[Phillip J. Eby]

At 04:25 PM 5/23/00 -0400, Dan L. Pierson wrote:
>I just added some stuff to the PTK Wiki at
>http://www.zope.org/Products/PTK/ZWiki/RefactoringPTK on PTK
>Membership issues.  After reading it, I realized that I should
>probably post this possibly controversial comment here as well:
>
>User management screens and methods. The only real reason that PTK
>needs special hooks into the UserSource is that UserSources have no
>protocol for adding, changing and deleting users. It would be very
>helpful if LoginManager would add such a protocol, otherwise products
>like PTK have to become intimate with the internals of the
>UserSources to implement them, which is exactly what ZPatterns was
>supposed to avoid in the first place!

The protocol doesn't exist, because UserSources aren't required to
implement any way to add user objects.  Technically, it is up to the user
of a LoginManager to add a method to its Methods tab to do this.  If a user
source supports adding, then that method can simply call
usersourcename.addUser (or newItem) and then fill in the details.  As for
changing and deleting, those methods belong to the LoginUser, not its
UserSource.

The PTK should not hook into the UserSource directly.  It is, however,
quite proper to include a method in the LoginManager itself which talks to
a specific UserSource.  This is a method delegation in keeping with the Law
of Demeter.  And it actually serves a purpose...  giving you a place to
configure *which* UserSource the user will be created in.

Suppose, for example, that you have three UserSources.  One runs off an SQL
db of paying customers, a second from an LDAP db of staff editors, and a
third that's a PersistentUserSource of the Zope admin/developers manning
the site?  Each has different security requirements, let alone data and
procedures needed to add a user to them.  How would you propose that the
LoginManager select among them when asked to "addUser"?

In general, I have been reluctant to add "native" object creation
facilities to Specialists, including LoginManager.  This is because I have
not thought of any good way for the caller to specify criteria for their
creation that doesn't amount to either "do whatever you want" or "use this
particular Rack".  Lacking any way to abstract this, I have felt it better
to leave it up to the person configuring the Specialist to insert a
constructor appropriate to the specific needs of the application they are
building.  This is why Racks have a built-in "add" protocol, but
Specialists do not.

As always, I am open to suggestions.  Ty and I batted this around with Mike
Pelletier a few times, with ideas like "use the first one that supports an
add protocol", and "have a parameter for which one", but we always kept
coming back to the simple fact that only the application designer knows for
sure what they want, and that at best we might in future add a checkbox to
the LoginManager creation form that would create some default methods based
on the assumption that there would only be one UserSource and that it would
be capable of adding items.