[Zope-PTK] Membership Component Preview Release

Kevin Dangoor kid@kendermedia.com
Sat, 17 Jun 2000 17:22:12 -0400


----- Original Message -----
From: "Dan L. Pierson" <dan@sol.control.com>
To: "Kevin Dangoor" <kid@kendermedia.com>
Cc: <zope-ptk@zope.org>
Sent: Friday, June 16, 2000 11:12 AM
Subject: [Zope-PTK] Membership Component Preview Release


> Kevin Dangoor writes:
>  >     I have pulled the Membership functionality out of the PTK and
created a
>  > Membership product. This is an early release and shouldn't be used for
>  > anything production. No compatibility is guaranteed for future
releases. I
>  > wanted to get this out there to get some feedback.
>
> I finally got a chance to try this out.  When I try to add Membership
> to a clean CVS Zope (with the minimum other stuff needed for
> Membership) I always get a "Passwords don't match" error whether or
> not I specify an initial user.

I'll probably take a look at this tomorrow or Monday. I *thought* that was
working, but I don't think the last tests I did against it involved a root
folder that had a UserFolder acl_users. (Funny how code that worked at one
time stops working later on... I can see why the extreme programming folks
stress testing :)

> But wait!  There's more :-)  The add form shows both the warning about
> overwriting an existing LM AND the new Membership stuff.  As I read
> installMembership, this shouldn't happen.  I wonder if
> installMembership being a DTML Method rather than a DTML Document
> might have something to do with these problems?

Hmm... It *should* give you a warning if you have a UserFolder and then
provide the rest of the installation form for Membership. Is that not what
you saw? (If you have a LoginManager already, it doesn't issue warnings...
it just assumes that you want to upgrade/install the higher-level interface
methods into the LoginManager.)

> Also, I'm not sure that MemberMixin should have the toolbox methods for a
> separate Membership system.  Of course removing them may mean yet
> another mixin for full portal member classes...

I agree that this could be confusing, but I figure that they don't really
waste any significant resources... so it's probably better to just use the
same mixin to keep the code consistent. What do others think?

Kevin