Difference between revisions of "Framework"
| Line 3: | Line 3: | ||
== Component Registry == | == Component Registry == | ||
| − | The central class to the geWorkbench framework is <tt>ComponentRegistry</tt>. This class is responsible for maintaining look-up tables of all active | + | The central class to the geWorkbench framework is <tt>ComponentRegistry</tt>. This class is responsible for maintaining look-up tables of all active plugins (known herein as ''components''). It also keeps track of the publish/subscribe behavior of the plugins. The <tt>ComponentRegistry</tt> makes use of CGLIB (http://cglib.sourceforge.net) to intercept methods and apply framework functionality. This will be covered in detail in the following sections. |
| + | |||
| + | Note the following definitions: | ||
| + | |||
| + | ; Plugin : The implementation of a geWorkbench add-on. | ||
| + | ; Component : An instance of a plugin active in geWorkbench. Note that it is possible for there to be zero or more components for each plugin. Typically, however, there will be just zero or one components for each plugin. | ||
== Component Instantiation == | == Component Instantiation == | ||
| − | An XML configuration file specifies which | + | An XML configuration file specifies which plugins should be instantiated in to components. This is parsed by a set of Apache Digester directives (http://jakarta.apache.org/commons/digester). Also parsed is a plugin-specific configuration file. This file has the same name and path as the component class file, but it has a <tt>.cwb.xml</tt> extension. This file includes some metadata about the plugin, such as the location of its help files, the area of the visual interface that the component should be installed, and what menu items it responds to. This metadata is stored in a class called <tt>PluginDescriptor</tt>. The configuration engine creates the <tt>PluginDescriptor</tt> object and passes it on to the <tt>ComponentRegistry</tt>. There, the component is instantiated and a CGLIB wrapper is applied. The <tt>ComponentRegistry</tt> stores the component and its associated descriptor for later use. It passes back the instantiated component to the configuration engine. In the case that the component is an instance of a visual plugin, the configuration engine ensures that the component is added to the appropriate visual area. |
| + | |||
| + | == Publish/Subscribe == | ||
| + | |||
| + | Components communicate via a publish/subscribe model. Plugins will include | ||
Revision as of 12:50, 14 March 2006
This document outlines the operation of the geWorkbench framework. This information could be of use to plugin developers who desire a deeper understanding of geWorkbench.
Component Registry
The central class to the geWorkbench framework is ComponentRegistry. This class is responsible for maintaining look-up tables of all active plugins (known herein as components). It also keeps track of the publish/subscribe behavior of the plugins. The ComponentRegistry makes use of CGLIB (http://cglib.sourceforge.net) to intercept methods and apply framework functionality. This will be covered in detail in the following sections.
Note the following definitions:
- Plugin
- The implementation of a geWorkbench add-on.
- Component
- An instance of a plugin active in geWorkbench. Note that it is possible for there to be zero or more components for each plugin. Typically, however, there will be just zero or one components for each plugin.
Component Instantiation
An XML configuration file specifies which plugins should be instantiated in to components. This is parsed by a set of Apache Digester directives (http://jakarta.apache.org/commons/digester). Also parsed is a plugin-specific configuration file. This file has the same name and path as the component class file, but it has a .cwb.xml extension. This file includes some metadata about the plugin, such as the location of its help files, the area of the visual interface that the component should be installed, and what menu items it responds to. This metadata is stored in a class called PluginDescriptor. The configuration engine creates the PluginDescriptor object and passes it on to the ComponentRegistry. There, the component is instantiated and a CGLIB wrapper is applied. The ComponentRegistry stores the component and its associated descriptor for later use. It passes back the instantiated component to the configuration engine. In the case that the component is an instance of a visual plugin, the configuration engine ensures that the component is added to the appropriate visual area.
Publish/Subscribe
Components communicate via a publish/subscribe model. Plugins will include
