Start page / Plug-In Development / Implementation and Deployment / Module Architecture / Component Model
Component Model
Client plug-ins are provided to FirstSpirit servers in FirstSpirit Module (FSM) files. FSM files follow a set format that allows FirstSpirit servers to determine individual components specified in the module description file and how to work with resources as modules are deployed to a server.
A FirstSpirit Module consists of one or several components. Generally, components are used to advertise the classes that implement FirstSpirit plug-in interfaces to the server.
In this guide, two component types are introduced, which will be used to deploy client plug-ins:
- public
This component type is used to advertise classes that implement plug-in interfaces to the FirstSpirit server. For each plug-in class, a separate component will be defined. - web-app
This component type is used to advertise resources required to add an FSM's plug-ins to ContentCreator applications. When a web-app component is added to a ContentCreator application, the resources (at least one JAR file and other, optional files) are merged into that customized web application.
These components are specified in the file module.xml, which is a mandatory part of the FSM file.
Additionally, at least one Java Archive (JAR) file and an optional number of resource files will be included in the FSM file. The JAR file(s) will include any number of Java classes that implement the plug-in interfaces as well as other classes that provide functionality used in the plug-in code. You may also include JAR files containing third-party libraries; for deployment to ContentCreator, these JAR files should also be specified in a web-app component so these archives can be rolled out to project-specific web applications as well.
The structural diagram below illustrates the relationships between components (as described in module.xml) and resources stored in the module (classes stored in a JAR file as well as other resource files).
 |
Because ContentCreator plug-ins are deployed on a per-project basis, it is important to group plug-in implementations (i.e. Java classes) in such a way that client extensions that are to be active in only one project can be deployed separately. This can be accomplished by
As each of the above methods ensures that individual JAR files with distinct contents are created, it is possible to conduct a fine-grained deployment of plug-ins to individual projects' ContentCreator web applications. |
Referencing Plug-In Classes in Component Blocks
FirstSpirit identifies available plug-ins by inspecting the component blocks in a module's module.xml file. As such, the top-level classes for each client plug-in kind must be referenced in such component blocks, usually as a public component.
Implementations of the following API interfaces must be referenced in module.xml:
- WebeditInlineEditItemsPlugin
- Executable
- WebeditToolbarActionsItemsPlugin
- WebeditReportPlugin
Page Status and Workflow Display plug-ins
- WorkflowGroupProvider
- StoreMapping
- Executable
If any of these implementations make use of other classes (be they implementations of FirstSpirit API interfaces or classes without inheritance), these additional classes do not need to be referenced in module.xml, but must be made available with the FirstSpirit Module's JAR files in order to be made available to any project-specific ContentCreator web application that is to use a given plug-in. These additional classes can either be stored in the same package as the accessing plug-in class or must be called using the fully-qualified class name including package path.