| 1 | | Create a plugin system for the web application that allow plugins to add menu items to the menu, |
| 2 | | toolbar buttons to the toolbars on list and view pages, and possibly also to other places like |
| 3 | | "Actions" or "Tools" column in some lists, etc. |
| | 1 | Create an extension/plug-in system for the web application that |
| | 2 | makes it possible to add menu items to the menu, toolbar buttons to the toolbars on list and view pages, and possibly also to other places like "Actions" or "Tools" column in some lists, etc. |
| | 3 | |
| | 4 | |
| | 5 | '''Implementation idea''' |
| | 6 | |
| | 7 | First, I think we should use the name ''extension'' or ''web extension'' so we don't confuse it with the existing plug-in system. |
| | 8 | |
| | 9 | The first use case we have is to make the MeV-launcher an extension, so I will use this as an example below. |
| | 10 | |
| | 11 | ''Extension point''[[BR]] |
| | 12 | Each place were it should be possible to add extension must be defined as an ''extension point''. The definition consists of an ID, based on the normal Java conventions, and a class. For example: |
| | 13 | ID=net.sf.basedb.clients.web.bioassayset.tools, class=ActionButton |
| | 14 | |
| | 15 | The ID must of course be unique. The class is a real class or an interface that extensions that attach to an extension point must provide an object/implementation of. The class/interface usually defines some attributes that is needed to create the visual appearance of the extension. The ActionButton may, for example, have the following methods: getImage(), getTitle(), getOnClick(). |
| | 16 | |
| | 17 | ''Extension''[[BR]] |
| | 18 | An extension extends an extension point with a specific implementation, for example, the 'Launch MeV' button. An extension itself should also define a unique ID, the ID of the extension point it should be attached to, and a factory class that can be used to create objects of the class specified by the extension point. We only need one instance of a factory class for each extension and it must be thread safe. The web core will use the factory class to create the objects needed for the presentation, ie. ActionButtonFactory will create ActionButton:s. The factory class can be initialised at startup with a set of configuration parameters. BASE should ship with some useful factory classes, for example: |
| | 19 | |
| | 20 | * ImmutableActionButtonFactory: Everything is fixed, the button has always the same icon, title and executes the same code when the button is clicked. |
| | 21 | * PermissionButtonFactory: The appearance is based on the logged in user's permission. The button can either be disabled or hidden unless a specific permission requirement is met. |
| | 22 | * etc... |
| | 23 | |
| | 24 | An extension can of course also provide it's own factory class, for example: MeVLauncherButtonFactory. In all cases the factory classes will be provided with information about the logged in user, the current item, etc. |
| | 25 | |
| | 26 | ''Extension registry''[[BR]] |
| | 27 | A central registry is needed were extension points and extensions can be registered. The registry is the main hub that is connecting all parts of the extension system. |
| | 28 | |
| | 29 | ''Auto-loading servlet''[[BR]] |
| | 30 | It should be possible to install/remove/update extensions on the fly on a running web server. To make this possible we need some kind of monitoring application that can automatically detect when things are changed. I think this is easiest implemented as a servlet marked to start when the Tomcat server is started. The servlet will for example monitor the /WEB-INF/extensions directory. |
| | 31 | |
| | 32 | To install an extension a new JAR file is added to this directory. To remove an extension the JAR file is simply deleted, and to update an extension the JAR file is replaced with a new one. The JAR file must of course follow a specific layout. |
| | 33 | |
| | 34 | When the servlet detects a change, for example a new JAR file, it will load information from the JAR file, register any extentions and extension points it can find with the central registry. When the registration has been completed the new extension becomes immediately visible in the web interface. Likewise, when the servlet detects that a JAR file has been removed, it will unregister all extensions/extension points that was present in that file. |
| | 35 | |
| | 36 | |
| | 37 | ''Extension JAR files''[[BR]] |
| | 38 | An extension should be packaged in a single JAR file. It must have an XML file at /META-INF/extensions.xml that describes the extension points and/or extension contained in the JAR file. This should be enough in the simplest case. In the case of the MeV launcher lots of other files are needed, but they can't be located in the /WEB-INF/extensions directory. I think it would be nice to simply have a single JAR file for an extensions. The auto-loader servlet could then extract all files in the /resources/ subdirectory and place those files in the /plugins/ directory on the Tomcat server. I am not sure exactly how this should be done at the moment, and if there is any risk of overwriting other extensions files or not. The JAR file may of course also contain actual implementations of factories and/or extension objects. A separate class loader for each JAR file is needed (if we want to be able to install/update/remove extensions independently from each other). |
| | 39 | |
| | 40 | |
| | 41 | ''Summary''[[BR]] |
| | 42 | In the simplest case an extension can be developed by just writing an XML file and packaging it in a JAR file. The extension is installed by simply putting the JAR file in a special directory on the server. An auto-installation servlet makes sure that everything is immediately visible in the web interface. Extra resources, such as images, javascript files and JSP pages, can also be included in the JAR file and will be extracted automatically by the auto-installation servlet. |
