UI Plugin Services

Overview

Frontend plugins in Bloomreach Content are independent components. However, when combined in an application, these plugins often need to interact. Plugins may trigger events that other plugins respond to, while some plugins may remain unaffected.

Plugins can communicate by sharing models. When a plugin provides an IModelService—which a Perspective does by default—other plugins can access this service to retrieve their IModel and receive notifications when the model changes.

To use this mechanism, extend the RenderPlugin class and override the onModelChanged() method. This method is called whenever another plugin updates the model. If your plugin needs to update its UI in response, call redraw().

For example, when a page includes a BrowserPlugin, selecting a node in the JCR tree triggers notifications to other plugins. This approach is used to display workflow plugins for nodes that support workflows.

public class ExamplePlugin extends RenderPlugin {

    public ExamplePlugin(IPluginContext context, IPluginConfig config) { 
       super(context, config);
    } 

    @Override
    public void onModelChanged() { 
         // repaint the plugin when the model has changed. 
        redraw(); 
    }
}

Advanced Plugin Communication Patterns

Plugins can support more complex interactions by registering services or trackers. Any object that implements IClusterable can be registered as a service. Several patterns are commonly used for these interactions.

Whiteboard Pattern

The whiteboard pattern applies the principle "don't call us, we'll call you" to client/server communication. Instead of registering directly with the server, clients register listener services with the plugin context. When notifications are needed, the server retrieves all listeners from the context and notifies them.

The model sharing mechanism uses this pattern. Plugins that need model change notifications register an IModelListener. The ModelService then uses these listeners to notify plugins of model changes.

Decorator Pattern

The decorator pattern allows services to be extended with additional interfaces. For example, the ITitleDecorator interface enables a Perspective to provide a title for display in the tabbed panel.

Framework-Provided Services

The framework provides several common services that plugins can access by well-known names.

IDialogService

The IDialogService allows plugins—including those without a user interface—to display modal dialogs. Subclasses of AbstractRenderService (such as RenderPlugin) can use the getDialogService() method to locate this service. Alternatively, use the plugin context and the service name IDialogService.class.getName().

To display a dialog, use the following approach:

IDialogService dialogService =
       context.getService(IDialogService.class.getName(), IDialogService.class);
dialogService.show(new ExampleDialog(context, flagService));

IPluginConfigService

The IPluginConfigService provides access to configurations for clusters of plugins. Retrieve it using the name IPluginConfigService.class.getName(). This service supports dynamic instantiation of plugin clusters.

For example, in the CMS, each editor instance has its own set of plugins and its own node model. To support this, each editor uses a separate ModelService, configured by the plugin that creates the editors.