At 12:07 PM 9/25/00 -0400, Andrew Wilcox wrote:
>The PlugInBase.manage_afterAdd() and manage_beforeDelete() methods
>dynamically checks if their container has the _addPlugIn() and
>_removePlugIn() methods before calling them.  Could this code be
>simplified by requiring containers support an add/remove PlugIn
>interface, with a default do-nothing implementation?

Sure, but that would be a change to the Zope core - ZPatterns is intended
to be an independent add-on.

>The PlugInContainer._addPlugIn() and _removePlugIn() will register a
>plugin with multiple groups.  However _findGroupFor() appears to
>assume that a plugin is associated with one plugin group.  What would
>be an example of a plugin that registered itself with multiple plugin

There isn't one, AFAIK.  The add/remove operations are slightly
overengineered  Early in the process we thought there'd be a need and that
PlugIns would be able to have multiple plug-in kinds.  Later on we decided
to keep it simple and support only one.

>The PlugInContainer directly accesses the __plugin_kind__ attribute of
>a plugin.  Could we have a plugin.kind() method instead?

As Jim likes to say, what problem are you trying to solve?  :)

> patches the Zope ProductContext class to add the
>_registerPlugInClass method.  Could we instead update the Zope
>implementation to provide a _registerPlugInClass method, that called
>the ZPatterns product if it was installed?

Again, that would be a Zope core change, and ZPatterns is intended to be an
independent add-on.  If at some later date there is a move to incorporate
PlugIns into the core, what you describe would of course make sense.
Although in that case, the necessary code would go straight into
ProductContext and not be a part of ZPatterns any more.

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to