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? :)
>PlugIns.py 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 -