[Zope-PTK] Hooks

[Shane Hathaway]

Fabio Forno wrote:
> I've just realized that in the new architecture there're no more hook
> methods that are called when some portal contents or their review state
> change. Is there a reason for this? Almost the same behaviour seems
> reachable overriding the changeStateFor method, but I was preferring the
> former solutions as it allowed to keep my additions and policies
> separated from the standard portal distribution.

The new architecture allows you to mix and match tools that come from
different sources, including tools you build yourself.  So if you want
to customize the workflow (there are many situations where a simple
"review state" is not at all adequate) then you can:

1) Subclass portal_workflow and replace the default instance.  Note that
you don't have to reconstruct the entire portal, just swap a component.

2) Expand the user interface for portal_workflow.  Right now, it has no
UI, so there's plenty of room for improvement.  It needs to be
configurable.

3) Modify portal_workflow to generate hookable calls.  If they seem
reasonable, they can be folded back into the distribution.

How is this different from the former situation?  The only way to keep
your changes separate from the standard distribution was to subclass. 
The advantage we have now is that it's easier to swap implementations of
different parts of the portal for better ones.

> Finally an advise request: which is the better way to extend the PTK and
> beeing able to keep synchronized with the PTK development? Is a good
> solution to make a new product and derive a ZClass from the Portal
> ZClass, adding there all personal changes and additions?

Now this is an issue that needs work.  It's easy to keep up to date on
filesystem-based data, but the through-the-web data gets obliterated by
every import of DemoPortal.zexp.  It think a possible solution involves
the following steps:

1) Zope can import and export entire branches, but it could be much
better at keeping objects in sync with external sources.

2) If we could achieve not only skins but the ability to make one skin
inherit from another, we wouldn't need to replace the portal interface
with every update.  People could customize while keeping up to date.

This issue really goes to the very core of separation of layers.  The
former architecture mixed the user interface with the underlying
functions.  The new architecture makes a strong distinction between the
UI and the logic: PTKBase now contains only minimal HTML/DTML.  So we
have at least two layers.

There is another separation of layers in there also: In DemoPortal, the
"Portal" base class contains a bunch of DTML methods that delegate the
work they do to the tools, then delegate the UI to the portal instance. 
So they act as a middle tier.  The change_password method, for example,
asks portal_registration to change the password, then defers to one of
two DTML methods in the portal instance to render the UI.

Some might say the middle tier is the "controller": it is the glue
between the "model" and the "view".  The former architecture mixed the
controller and the model into one.

So, OO experts, is this a good approach?  Can we make it better?

Shane