[Zope-dev] PTK thoughts

Andrew M. Kuchling akuchlin@mems-exchange.org
Wed, 19 Jan 2000 15:44:21 -0500 (EST)


I've looked over the notes about the Portal Toolkit, have just joined
the zope-ptk mailing list, and have a few thoughts.  (Still have to
read over the back archive, though...)

     * I find it strange that members are able to publish content at
       all.  For most of the portals I can think of -- Yahoo, My
       Netscape, etc. -- membership means you have access to various
       features that run off scripts or databases, and you have some
       sort of customized display.  The set of people who publish
       content is much, much smaller than the set of all members.
       Zope.org and community discussion forums are the only cases I can
       think of where members publish content, and only on 
       Zope.org do people see anything like a management screen.

       In essence, I'm wondering if Members should have no content
       management capability at all, and their management capability
       given to some class intermediate between Member and
       Contributor.  

     * Would it be possible to generalize the model of creating
       objects which get approved by a manager, so that you have
       almost workflow-like features.  Looking at the PTK from the
       point of view of the MEMS Exchange, we'd be interested in
       having more complex transitions, and transitions that can be
       triggered by different sets of people.

       For example, our workflow would look like this:

       * Member creates a Run object
       * An MX staff member looks at the Run, makes some comments, and
         bounces it back to the member, who revises it.
       * MX staffer looks at the run again, and approves the revised
         version.
       * 3 other Members with a certain role look at the run and
         approve it.  Various other people get notified about this.
	 
       The general abstraction is that there can be an arbitrary set
       of states, and some arbitrary criterion must be met before
       transitioning from one state to another, instead of only 2 
       approved/not approved states.  This is obviously more
       complicated, and probably too ambitious for the first version,
       but it could make the PTK a useful foundation for intranet
       applications, where you'd embody the way your business works in
       Python code.

BTW, I just re-read "Philip and Alex's Guide to Web Publishing" recently;
highly recommended.  Chapters 2 and 3 are especially applicable
to the PTK, and chapter 13 is also worth reading for Zopers.  It's
online at http://www.photo.net/wtr/thebook/, but it's still worth
buying a copy.

-- 
A.M. Kuchling			http://starship.python.net/crew/amk/
We tend to idealize tolerance, then wonder why we find ourselves infested with
losers and nut cases.
    -- Patrick Hayden