4.5.12. Creating the Rule Plug-in

After having implemented the rule class, the compiled class needs to be installed in Docmenta. Therefore a plug-in has to be created as described in Chapter 4.2, Creating a plug-in package. Besides adding the rule class to the classpath, the class also needs to be registered in the Docmenta plug-in API. This is done when the plug-in is loaded by invoking the registerRuleClasses method on the org.docma.plugin.ApplicationContext instance. That means, the implementation of the plug-in class has to be as follows (see Section 4.3.1, “Lifecycle methods” for details):
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
package myexample;
 
import org.docma.plugin.ApplicationContext;
import org.docma.plugin.Plugin;
import org.docma.plugin.PluginContext;
 
public class MyRulePlugin implements Plugin
{
public void onLoad(PluginContext ctx) throws Exception
{
ApplicationContext app = ctx.getApplicationContext();
app.registerRuleClasses("myexample.MyHTMLRule");
}
 
public void onUnload(PluginContext ctx) throws Exception
{
ApplicationContext app = ctx.getApplicationContext();
app.unregisterRuleClasses("myexample.MyHTMLRule");
}
}

Listing 4.5.3. MyRulePlugin.java

As you can see in 4.5.3: MyRulePlugin.java, the onLoad method registers the myexample.MyHTMLRule class, and the onUnload method unregisters it.
To create the plug-in package, the compiled classes and the resource file MyHTMLRule_en.xml have to be included in a zip-file as illustrated in Figure 4.6.9, “Auto-Format example package”:

Figure 4.5.2. MyHTMLRule plug-in package

Instead of placing the files in the web/WEB-INF/classes folder, the files could also be included as a jar-file and placed in the lib or web/WEB-INF/lib folder.
Following an example of the plugin.properties file:

id=my_htmlrule
version=1.0
plugin_class=myexample.MyRulePlugin
required_app_version = 1.9
config_dialog = false
load_type = next_startup

Listing 4.5.4. plugin.properties (content rule example)

In this example, the identifier my_htmlrule is used for the plug-in. Finally, an example of the locale.properties file, which just contains a localized plug-in description:

my_htmlrule.description = Content rule plug-in example
my_htmlrule.help_url =

Listing 4.5.5. locale.properties (content rule example)

Note that a help URL (my_htmlrule.help_url) is not specified, because our plug-in does not provide any configuration options that need to be explained. Furthermore, the rule class provides its own help through the getLongInfo method.
For details on creating a plug-in package see Chapter 4.2, Creating a plug-in package. The plug-in package can now be installed as described in Section 2.7.5, “Installing Plug-ins”:

Figure 4.5.3. Example rule plug-in loaded

Note that you have to restart the web-server for the plug-in to be loaded.
After the plug-in has been loaded, you can create a new rule that uses the newly installed rule class. See Section 2.7.6, “Rule configuration” on how to add a new rule. In our example we create a new rule with identifier my_example_rule (see Figure 4.5.4, “Adding a new rule”).

Figure 4.5.4. Adding a new rule

Note that the maxlength argument needs to be set for the check_length check. After having added the new rule, the "Content Rules" tab in the "Administration" workspace should list a rule with identifier my_example_rule:

Figure 4.5.5. Added example rule

After the rule has been installed and enabled, the rule can be applied on selected content- and section-nodes, by choosing the menu item "Consistency-Check" from the context menu. See Section 2.3.4.8, “Consistency-Check” for more information. Note that a user can enable or disable single checks in the consistency-check dialog. Furthermore, if a check is enabled for "Save", then the check is also applied to content in the content editor at the time when content is saved (see Section 2.3.8.1, “Basic editing”).