You are not logged in Log in Join
You are here: Home » Download Zope Products » Content Management Framework (ne "PTK") » ZWiki » RefactoringPTK

Log in
Name

Password

 
 

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.