[Zope-PTK] PTK II

[Phillip J. Eby]

At 04:08 PM 7/28/00 -0400, Shane Hathaway wrote:
>
>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
>

Makes sense to me - I think.  Let me see if I understand.  I'll avoid
ZPatterns terminology, since it's not necessarily needed (although it's a
good fit).  The Portal will be an object that contains a Membership object,
a Workflows object, and a Discussions object.  Then either the portal
content objects themselves or the standard_html_head/footer will get
toolbox items from these functions by way of the Portal object.  Is that
essentially correct?


><lots of good stuff deleted>
>
>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.

Hm.  I'm not sure why discussability wouldn't generate a catalog query...
but I guess that's a seperate issue.


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

Pretty much.  

By the way...  The current release of ZPatterns allows for DataSkins to
delegate *any* protocol they want to a Data Plug-in.  By that, I mean that
if you want to create a delegation protocol for discussability or reviewing
or something of that nature, you can now do it in a Python class derived
from DataSkin.  You then can create Data Plug-ins that register themselves
as supporting that interface, which can be plugged into Racks or
Customizers.  What this would allow you to do is, is make the Portal derive
from "Folder w/Customization Support", thus giving it a "Customizers" tab
where you could add customizers for each portal content type you want to
customize.  These customizers can then contain the appropriate plug-ins.

Unfortunately, this new "delegate anything" ability is not at all
documented.  I expect to be using it soon to add delegation of local roles
computation (rule-based local roles), and delegation of content control
(imagine a Folder that contains ZODB objects mixed with SQL, LDAP, or
filesystem objects).  Once I've done those, there will be four examples of
delegation protocols, but right now there are only two (attributes and
sheets).

The other thing that would be needed to take advantage of this delegation
capability, would be better ZClass support for PlugIns.  I would very much
welcome code contributions that would get PlugIns in the right direction
there.  Specifically, one should be able to create a PlugIn or
PlugInContainer as a ZClass, complete with adding/setting up PlugInGroups
in the management screens for the ZClass.

Now if only there were more weeks in a day...  :(