RefactoringPTK

I (Kevin Dangoor, aka tazzzzz) started this page to keep track of thoughts on refactoring the PTK. The biggest reasons for refactoring what is there are flexibility and customizability. This is probably a good time to do a refactoring, because the PTK is not in widespread use and Phillip Eby's ZPatterns are providing us with new ways to approach PTK customizability.

Currently, the PTK provides these capabilities:

• Content review and cataloging

• Membership

• Wizards and a user friendly object management front end

• Toolboxes

It would be nice for people to be able to pick and choose which parts they want to use and customize those pieces for their needs.

Membership

LoginManager, which was initially bundled with the PTK, is now available as a separate Product. It is a highly configurable system for managing users, and would be useful to many outside of the PTK. The PTK Membership component should really just be LoginManager with customizable methods for user registration, user management, etc. I'm not what the best way to package this is. Perhaps subclass LoginManager and then provide default DTML methods for user registration?

[dlpierson] There are basically three parts to PTK membership support:

1. A UserSource? for LoginManager. Phillip Eby says that LoginManager 0.9 will include a PersistentUserSource? of its own, so speciallized PTK stuff may be able to go away.

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

   Phillip Eby explained the ZPatterns way of doing this in an email dated May 23, 2000:

         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"?
   
   

   The reference to "add a method to its Methods tab" is implemented at the Python level by calling manage_addDTMLMethod, manage_addExternalMethod, etc. on the Portals acl_users (i.e. the LoginManager). Methods can be added to a specific UserSource? in the same way. GUF already requires that user manipulation methods be added or acquired; LoginManager's GenericUserSource? handles the same methods as GUF so these could probably be a starting point.

   So, assume everything is set up. How does the PTK add a user?

   • PTK calls acl_users.addUser (a method it added to acl_users).

   • acl_users.addUser figures out which UserSource? to talk to and calls its addUser method.

3. Some specialized user methods for PTK. These are implemented in MemberMixin?, which is intended to be combined with a normal user base class (e.g. LoginManager.UserSources?.LoginUser?) in a ZClass? that actually implements a user. All this actually works pretty well today.

   There is a comment in MemberMixin? which claims that the user's password, roles and domains will be moved to a special property sheet someday. I think that this is actually a bad idea unless LoginManager changes to do this for all users. Id, roles and domains are part of the basic user model that Zope requires all acl_users like things to support -- you probably want to keep that information in a separate location from user-controllable things like email address, hair color, etc.

[dlpierson again] After some more discussion it's looking like the correct thing to do is to:

1. Make the PTK's Membership component require LoginManager, with Membership manipulation as discussed in point 2 above.

2. Make this Membership component separate from the PTK. This may turn out to be the easiest of the PTK pieces to break out.

Content Review and Cataloging

This is something for which ZPatterns will be very helpful. Using zpatterns, content can be configured on a folder by folder basis to look different, be indexed differently and even be stored differently if so desired.

From an email from Phillip Eby on 5/21:

    Specifically, you use an InjectionFolder-derived folder
    somewhere in the path to where your PortalContent DataSkins will be 
    stored. You add DataInjectors to the approriate tab of the 
    InjectionFolder, configuring them for what object types they will serve 
    as DataManagers for. Last, but not least, you add IndexingAgents, 
    RuleAgents, AttributeProviders and SheetProviders to each DataInjector 
    to  configure it. One kind of AttributeProvider you can add will be 
    ClassExtender - a simple container that lets you add methods and 
    properties which will be set in the DataSkins.  (ClassExtender probably 
    won't get built until the 0.5.0 cycle, however.)
    This all sounds rather complex, but that's probably due more to the 
    funky names than anything else.  In all probability the front-end name 
    of "DataInjector" will be "Customizer", and InjectionFolder will 
    be "Folder w/Content Customizer Support".  So, in plain English...  You 
    put your portal content objects somewhere underneath a folder with 
    customizer support if you want to customize them.  You add a customizer 
    to that folder for each kind of thing you want to customize.  And you 
    put things in each customizer for each data management, indexing, 
    rule-handling, or other customization you want to make.

Packaging

The current PTK design is a nice, all-in-one package for beginners. It would probably be good to provide a plug and play PTK system in addition to individual customizable components. One way to do this would be to configure a basic Portal Data.fs file. The user can either replace their new Zope's Data.fs file with that one, or mount the other Data.fs underneath their existing database.