History for PlugInsIntroduction

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

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

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!"