Creating a custom button class

You can create custom button classes that dynamically add custom actions to the authoring interface. Custom buttons allow you to integrate additional third-party tools into the authoring interface without using a custom element. For example, you can use a custom button that adds automatic profiling of a content item or that adds or changes elements on the item forms.

About this task

Each extension adds an optional single button to the Read or Edit mode of an item form. When invoked, the extension can perform any data modification on the item. Even in read mode, the extension can change the item state and perform save operations. To create a custom button plugin, you must create a custom button class and then register the class by deploying it on the server.

Procedure

  1. Create a java class that implements the interface com.ibm.workplace.wcm.api.extensions.authoring.AuthoringAction. This class must implement the following methods:
    public boolean isValidForForm(final FormContext formContext) {}
    This method flags whether the button should be included on the button bar or ignored for the open item. Any uncommitted changes made to the document contained within the form context will be discarded when this method executes. The method is invoked each time the page is rendered to limit performance impacts. Use the target authoring form for formContext.
    public int ordinal() {}
    This method returns a number that determines where the button is placed relative to any other buttons created by other AuthoringAction classes. The button with the lowest number is listed first.

    See the Javadoc documentation for further information. The Javadoc files for Web Content Manager are located in the wp_profile_root/installedApps/node_name/wcm.ear/ilwwcm.war/webinterface/api-javadoc directory.

  2. Implement the ActionResult execute(final FormContext formContext) method, which is invoked when the user clicks the button.

    Any uncommitted changes made to the document contained within the form context will be discarded when this method executes. Use the target authoring form for formContext.

  3. A plugin.xml file is needed whether the deployment is done using a WAR or EAR, or using a loose jar. If deploying via an application in a WAR or EAR, include the plugin.xml file in the application's "WEB-INF" folder. When using a jar, include the plugin.xml in the root of the jar. 
    <?xml version="1.0" encoding="UTF-8"?>
<plugin id="com.ibm.workplace.wcm.sample.authoringaction"
        name="Sample Authoring Action Extension"
        version="1.0.0"
        provider-name="IBM">        
  <extension
     point="com.ibm.workplace.wcm.api.AuthoringAction
     id="SampleAuthoringAction" >
     <provider class="com.ibm.workplace.wcm.sample.MyAuthoringAction"/>
  </extension> 
</plugin>

What to do next

  • The ID of each plugin must be unique.
  • You must replace the plugin ID specified in this example, com.ibm.workplace.wcm.sample.authoringaction, with a different ID for each extension you create.
  • Each AuthoringAction extension is represented by a single <extension></extension> tag.
  • The value of the point attribute must be com.ibm.workplace.wcm.api.AuthoringAction.
  • Provide an id value of your choice.
  • Specify the provider class for your AuthoringAction extension.
Naming conventions:
If you create a new plugin application with the same names and IDs as an existing plugin, the new plugin may override the first. When creating plugin applications ensure that the following are unique across your system:
  • The plugin ID, plugin name and extension ID of the plugin.xml file.
  • The fully qualified class name plus path of all classes within the application.
  • The file path of any files within the application.