[Zope-PTK] PTK II

[Dan L. Pierson]

Shane Hathaway writes:
 > 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.

I certainly agree that separating PTK into a generally useful toolkit
and a default/example framework built out of that toolkit is the way
to go.

That said, the framework is very important.  Not just for its direct
value to users, but because it's a nearly essential component for
being able to validate that the toolkit is actually capable of
producing content manager configurable frameworks!

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

Absolutely!

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

What is the difference between this and the Membership product effort
other than some minimal support for default acl_users membership?

<Confession>
I suspect that supporting default acl_users for Portal membership is a
poor idea.  I can't prove it, but somehow I'm more comfortable with
site managers being defined in a separate area that Portal members
have no access too.  Please feel free to convince me that I'm just
being silly and paranoid here :-)
</Confession>

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

That means that we first need to defined a good interface for this
component.  Of course this is true for all, but this component is
described in such a way that I think that most serious uses would want 
to replace it.

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

OK.  I like this being a separate interface, especially since I've
long wanted general DataSkins-based discussion support (well, it did
have another name way back then :-)).  I think that it's very
important that it be cheap and easy to make all or almost everything
on a site discussable.  I also think that site management would be
much easier if the discussions did not have to live in the same ZODB
as the rest of the site.

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

OK, here I lose you.  I'd like to see an example of what you think
these singleton objects might look like.