[Zope-PTK] PTK II
Dan L. Pierson
Fri, 28 Jul 2000 16:27:53 -0400 (EDT)
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
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.
> 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?
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 :-)
> 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
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.