PlugInsIntroduction

What are PlugIns, and what does this pattern do?

PROBLEM

You are creating an object which you want to be end-user configurable and extensible. You need to manage one or more sets of user-selected collaborator objects which extend your base object. These collaborator objects may be of multiple types, although within a given set, they must all support the same collaboration interface. You don't know in advance what types these objects will be, since you want users to be able to create arbitrary implementations of your collaboration interface. You also want to store, add, and manage these collaborators like regular Zope sub-objects (so that acquistion, etc. still work), but don't want the collaborators to show up on the Folder add list. Finally, for clarity, you'd like each set of collaborators to have their own management tab (ala Contents), but not show up on your Contents tab (if you have one).

../TySarna: also, they allow ordering of PlugIns within a group, which is important for things like LoginMethods and Racks

SOLUTION

PlugInContainers are Folder-derived objects which can have specialized collaborators, namely PlugIns. PlugInContainers have management tabs (implemented by PlugInGroups) for each collaboration interface (__plugin_kind__). PlugIn classes are registered by PlugInKind, and PlugInContainer classes have PlugInGroups which determine what kind(s) of PlugIns can be added on each management tab.

EXAMPLE APPLICATIONS

LoginManager has PlugInGroups for LoginMethods and UserSources. If ZCatalog used a PlugInGroup for Indexes using a plugin kind of "ZCatalog Index", users could create arbitrary kinds of index objects without touching ZCatalog itself. And so on.

ZPatterns also makes extensive use of PlugIns. DataManagers (such as Customizers and Racks) are PlugInContainers with PlugInGroups for AttributeProviders, SheetProviders, IndexingAgents, and RuleAgents. CustomizerFolders are regular Folders, but with a PlugInGroup for Customizers.

LIMITATIONS

Due to the way PlugIn classes register their permissions and constructors, they must be implemented directly in Python. It is theoretically possible to create specialized constructors that would do the same magic for ZClasses, but it would appear to require Fulton-like Zen to do so. As Jim would say, "waaaa!"