redesign of plugin architecture for dmanclient
Need to redesign the plugin architecture for dmanclient so that it supports
dynamically added menus, toolbar items, and inter-plugin services. See the
diagram in cvs under design/plugin-services.gif for an overview of a potential
#3 Updated by Matt Jones almost 19 years ago
New design of plugin and services architecture has been checked into CVS under
the tag FRAMEWORK_REDESIGN_BRANCH. Now the ClientFramework finds the name of
plugins from the configuration file and loads them. This involves giving the
plugin an opportunity to register menus, toolbar items, and services, and add a
tab in the main user interface. Services are generic functions that the Plugin
will execute for other plugins, identified by name. Data is passed between
plugins using generic ServiceRequest and ServiceResponse objects. The
"morpho-design.vsd" visio file in the design module contains a UML class diagram
and a UML sequence diagram illustrating this architecture and the interactions
between plugins wrt services.
Each plugin can register a single tabbed pane that is inserted into the main
user interface. Our current plans are that there will only be one tab (for the
users data list), and that all other UI frames needed by plugins will be
implemented as independent windows. The plugin can (and should) register these
windows as they are created, at which point they become visible in the "Window"
menu that is implemented by the framework. Plugins should remove windows from
the framework when they are deleted or hidden. Dialog boxes and wizards that
are modal need not be listed in Windows menu, but generally non-modal windows
should be listed (registered) while they are visible.
Still to do:
1) Generalize menus so plugins can insert them in specific places,
not just append. (this is problematic becase determining an absolute index is
non-trivial). Add shortcut keys to menu items.
2) Generalize toolbars so that additional kinds of widgits can be inserted
(like checkboxes and textboxes) by plugins.
3) Add an API for communicating with Metacat. This will probably involve
creating a MetacatRequest object and a MetacatResponse object that can be
passed. This could possibly be implemented as a service that communicates
with Metacat, but might be simpler as direct access methods in the framework.
#4 Updated by Matt Jones almost 19 years ago
Added menu placement features, so now plugins can determine the order of menus
and menu items.
Added utility routines for communicating with metacat so now plugins need not
know the network communication issues associated with sending data to metacat.
See the design/morpho-design.vsd Visio file for an overview of the API.