This article covers a Bloomreach Experience Manager version 11. There's an updated version available that covers our most recent release.

UI Plugin Application

Web applications that are completely configured from the repository consist of one page: "Home". Applications consist of a configured collection of plugins. The configuration is stored in the repository under  /hippo:configuration/hippo:frontend.

Example

The example below shows two application configurations ("foo" and "bar").

[repository root]
+ hippo:configuration
  + hippo:frontend
    + foo [frontend:application]
    + bar [frontend:application]

Each application has a plugin that registers an IRenderService under the name " service.root". The Home page in each application adds the service's Wicket component (see IRenderService.getComponent()) to itself when this service registers. The plugin must implement IRenderService, a feat most easily accomplished by extending the RenderPlugin class. This plugin registers itself as the service, and also provides itself as the Wicket component to wire into the hierarchy.

public class RootPlugin extends RenderPlugin {

    public RootPlugin(IPluginContext context, IPluginConfig config) {
        super(context, config);
        addExtensionPoint("extension");
    }

}

When the plugin is instantiated, it registers itself as the " service.root" render service (when configured correctly). It listens for other (render) services that register under the service name that "extension" is an alias for. When such a service registers, it is added to the component hierarchy. If no such service exists, an empty panel is shown. The plugins that are configured in the repository node structure must therefore correspond to missing Wicket components in the HTML for RootPlugin. For example, if the above root component has this HTML:

<html xmlns:wicket="http://wicket.apache.org/">
  <wicket:panel>
    <p>
      <div wicket:id="extension">[sub plugin will be rendered here]</div>
    </p>
  </wicket:panel>
</html>

then the repository structure that will generate the correct component hierarchy is:

+ hippo:configuration
  + hippo:frontend
    + application
      + cluster [frontend:plugincluster]
        + RootPlugin [frontend:plugin]
        | - plugin.class     = org.example.RootPlugin
        | - wicket.id        = service.root
        | - wicket.extension = service.extension
        + subPlugin [frontend:plugin]
          - plugin.class = org.example.subPlugin
          - wicket.id    = service.extension

Both frontend:plugin nodes, RootPlugin and subPlugin, need to have a property plugin.class, which contains the full class name of the plugin.

Did you find this page helpful?
How could this documentation serve you better?
On this page
    Did you find this page helpful?
    How could this documentation serve you better?