[Zope-PTK] Hooks

Fabio Forno sciasbat@inorbit.com
Fri, 18 Aug 2000 13:43:38 +0200


Shane Hathaway wrote:

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

In my not very deep Zope experience, the first two options need
sublassing and making a new product having PTKBase and also PTKDemo (If
you want to keep all the good things there are in there ;)) classes as
base classes. This can be done both at low level python code or with
ZClasses, I think it depends on the control you need. Anyway for much
more simple tasks, when you need just to add some functionality in
response to certain actions and all the base is good for you, I think
that hooks may be a great shortcut. 
 
> 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