Shane Hathaway shane@digicool.com
Fri, 28 Jul 2000 16:08:09 -0400


What do you think of the following direction for the development of

I envision PTK as not a framework but a toolkit.  A framework is a
thing which is mostly built but needs customization.  It's like leasing
office space.  A toolkit is less restrictive but more flexible.  It's
like having the tools and materials to build your own office space.

So PTKBase should be a toolkit while PTKDemo is a framework built from
that toolkit.

As I look over PTKBase and PTKDemo, I see little evidence of
separation.  I wanted to move the five basic content types from PTKBase
to PTKDemo, but discovered that DiscussableItem inherits from Document,
one of the content types.  This means either PTKBase would depend on
PTKDemo or all the Discussable code gets moved to PTKDemo. 
"Discussable" should be a feature of PTKBase, not PTKDemo.  This is
evidence of an architecture problem IMHO.

So I came up with an idea.  What we want to be able to do is have a set
of "tools" at the base of the portal.  These tools would include:

  - Membership database
  - Workflow attribute access
  - Discussion access

The default membership database would be a thin layer on top of the
acl_users object.  It could be replaced with a ZPatterns specialist
that looks up users from any number of sources.

The default workflow attribute access tool would query documents about
their workflow status, as is done now.  But it should be possible to
retrieve and store workflow status in another way, such as from context
or using a specialist.  This could be achieved by replacing the default

The discussion access tool would enable us to solve a problem we have
right now: every view of any portal content generates a catalog query. 
That's not necessarily a good thing.  The discussion access tool could
govern the storage of discussion information.

Basically, where PTKBase currently uses subclassing to achieve
membership (as opposed to simple users), workflow, and discussability,
we should instead use singleton objects that add capabilities without
subclassing (although the initial implementation will make use of
existing subclasses.)  I think this is exactly what Phillip's vision is
for ZPatterns.