History for RefactoringPTK

??changed:
-
  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":/Members/pje/Wikis/ZPatterns/HomePage 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":/Members/pje/Wikis/ZPatterns/HomePage 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.