[Zope-PTK] Membership packaging

[Kevin Dangoor]

----- Original Message -----
From: "Phillip J. Eby" <pje@telecommunity.com>
To: "Kevin Dangoor" <kid@kendermedia.com>; <zope-ptk@zope.org>
Sent: Sunday, June 04, 2000 11:02 PM
Subject: Re: [Zope-PTK] Membership packaging


> At 09:51 PM 6/4/00 -0400, Kevin Dangoor wrote:
> >The "Portal" object is then simplified to just add a LoginManager with
all
> >of the Membership bits.
>
> If I may suggest, one very straightforward way of doing this is simply to
> create a "Factory"/constructor in a Zope product that asks for the
> necessary settings, then creates a LoginManager and throws default methods
> in it.  Even with the current version of LoginManager, I believe that it
> should not be necessary to go to Python code to make such a constructor;
> everything should be callable from DTML.

I had thought of that possibility as well. I agree that it is
straightforward to do. The only disadvantage is that it adds one more item
to a possibly overlong Add menu.

One thing I'll also need to look into is dealing with this scenario:
1) Site manager is logged in as superuser, wants to replace root acl_users
with membership system
2) Uses the Membership system constructor, which replaces acl_users with
LoginManager (note to self: big red warning message goes here)
3) Membership constructor then needs to add methods to LoginManager... but
can't, because superuser is logged in. (I'll look at how LoginManager deals
with this now.)

> Ty has actually proposed that we add a wizard registration mechanism to
> ZPatterns, so that one could easily install this kind of wizard into a
Zope
> site, and then have it show up on a "wizard menu" for each object whose
> meta_class has wizards registered.  So if someone created a "Membership"
> wizard that was registered under LoginManager's meta_type, then it would
> show up on a menu which would appear immediately after you added a
> LoginManager.  You could then pick any of the LoginManager-related setup
> wizards and customize your LoginManager.  Similar wizards would be handy
> for various other ZPatterns systems.

This would be nice. You could have a ZODB Membership wizard and an SQL
Membership wizard. The various types of PortalContent (if based on
DataSkins) would be able to have wizards as well, then...

> >It seems to me that there should also be a setting for whether the cookie
> >given to the user for cookie authentication is permanent or just for that
> >browser session. I could see people wanting it either way. (Or maybe the
> >setting should be number of minutes that the cookie should last, with "0"
> >meaning permanent?)
>
> This could be done using a LoginMethod subclassed from
> BasicCookieLoginMethod, or by submitting a patch (hint, hint).

I'm guessing this will be easy to do... it's more just a matter of figuring
out the right UI for it.

>  A
> TokenCookieLoginMethod, to support GUF-style token cookies, might be good
too.

Yes, tokens are good. I probably won't get around to implementing them
myself, because there are other things a little higher in my current queue.

> >How should the portal manager add properties to the user? Should they
> >replace the class or extend it through some mechanism (sheet/attribute
> >providers?)? If the manager changes the class used for the users, what
> >happens to the previously defined users?
>
> In a PersistentUserSource/PersistentRack, nothing happens to the previous
> users if you change the class.  If your users are stored external to ZODB,
> they all effectively change to the new class as of the next transaction.
> There's a note in the Rack code (the base for UserSource) that says where
> dynamic class migration could be done, but I haven't put the code in
> because I don't like "side-effect transactions", and dynamically migrating
> would cause a write to the ZODB just for reading the object.  On the other
> hand, I don't like making manage_setStorage go into every record and
> rewrite it, either...

OK. I don't think it is very difficult to write PythonMethods for converting
the data from the old class to the new, anyhow.

On a side note, I noticed that the existing PersistentUserSource doesn't use
a Rack (and, hence, doesn't use a BTree). I'd probably want to see that
change...

Kevin