[Zope-PTK] Integrating Membership with SMBUserFolder (was: [Zope-PTK] Integratingzope portal toolkit and ntuserfolder)zope portal toolkit and ntuserfolder)

[Tres Seaver]

Bill Anderson wrote:
> 
> Michael Bernstein wrote:
> ...
> > Note: Because membership is not reintegrated with the PTK as of yet,
> > joining does not create a member folder.
> 
> Note:
> PortalMembershipSystem will not do this anyway. That would be up to
> either the Upcoming CommunityMembershipSystem plugin for Memebrship.
> 
> This is where I part ways with how some of the PTK is going. PTK should
> _not_ deal with user management at all. Now doing things based on a
> trigger is fine, but having a member folder for content is a function
> that the user management item should handle, as it is part of user
> management, Why, you ask? Simple. What if you want a Member to be able
> to change their name, and not have to rename all their content, etc.?
> This is something CommunityMembershipSystem, will address: Usernames
> that are not tied  one-to-one with user ids.

The intent of the recent re-architecting was to make it possible to
supply different policies for things like member-folder creation/lookup,
simply by replacing the tool which implements that policy with another,
behind the same interface.  We are actively planning for several such
changes for an ongoing consulting project:

 * Multiple portals on a site sharing a single authentication source;

 * Deferred creation of member folders;

 * Addition of roles via "incremental registration" (as you need the
   permissions for a new role, you supply the data which the portal
   wants in exchange for the role).

All of these changes will be focused in the 'portal_membership' object
(perhaps also the 'portal_registration' one);  the key is to find the
right separation points and interfaces, e.g., so that replacing the
membership system for the portal has zero impact on the code for the
content objects.
 
> "But in DemoPortal..."
> The part that has become a problem, is that people are expecting
> DemoPortal to _be_ the PTK. It isn't, nor should it. We have to remember
> to seperate the Demo from the Product.

We see the "Demo" as performing several key functions (note that these
are goals, not claims):

 * document the intent of the framework, by providing working
   implementations of its interfaces;

 * provide an "out-of-the-box" useful implementation;  people should
   be able to do useful stuff with the PTK without having to implement
   dozens of interfaces;  they can then replace piecemeal the bits
   which don't quite work as they like;

 * force the development to stay at least somewhat grounded (i.e.,
   if we can't come up with a reasonable default implementation for
   and interface, then what good is it?)

> Membership is being built so that it can be used independently from the
> PTK. Even once PTK support has been added, it must be able to stand on
> it's own away from the PTK. As such, user management functions will be
> implemented with that it mind.

Sounds great!

Tres.
-- 
===============================================================
Tres Seaver                                tseaver@digicool.com
Digital Creations     "Zope Dealers"       http://www.zope.org