Create a custom button class

We can create custom button classes that dynamically add custom actions to the authoring interface. Custom buttons allow us to integrate additional third-party tools into the authoring interface without using a custom element. For example, use a custom button that adds automatic profiling of a content item or that adds or changes elements on the item forms. 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, create a custom button class and then register the class by deploying it on the server.

1. Create a java class that implements the interface com.ibm.workplace.wcm.api.extensions.authoring.AuthoringAction. This class 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 PORTAL_HOME/doc/Javadoc/spi_docs/com/ibm/workplace/wcm 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 
           name="Sample Authoring Action Extension"
           version="1.0.0"
           provider-name="IBM">          <extension
        point="com.ibm.workplace.wcm.api.AuthoringAction
         >
        <provider class="com.ibm.workplace.wcm.sample.MyAuthoringAction"/>
     </extension>  </plugin>

What to do next

• The ID of each plugin must be unique.

• Replace the plugin ID specified in this example, com.ibm.workplace.wcm.sample.authoringaction, with a different ID for each extension we 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 the choice.

• Specify the provider class for the AuthoringAction extension.

Naming conventions:

If we 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 the following are unique across the 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.

Parent Create custom plug-ins