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