Rule model extensions sample details

You use Rule Designer to run this sample.

Running this sample

  1. In the Rule perspective in Rule Designer, open the customrulemodel-rules project, and open one of the rule project rules. Some new properties are added in the Properties view.

    The definitions for the new properties are in the model file data/rulestudiocustommodel.brmx. All the business rules inside the customrulemodel-rules rule project are of type ExtendedRule, which extends the default type ActionRule.

    The new properties:

    • minorVersion, majorVersion, and patchLevel: Integer
    • productionLevel: Enum
    • authority: Hierarchy
    • requirement, territory, requestorMail and customerNames: String
    • The data for the Enum and Hierarchy property types is defined in the data file of the model data/rulestudiocustommodel.brdx, which is inside the rule project. For example, the definitions for productionLevel items and authority node values are in this data file.
  2. Change the value of the Region property. Now, edit the territory property. The list of choices is filled according to the value of the Region property. If you set the Region property to another value, Rule Designer cleans the territory property automatically.
  3. Create an ExtendedRule type action rule in the new action rule assistant (New  > Action Rule) by selecting ExtendedRule in the Type drop-down list selector.

    Look at the properties of the new ExtendedRule. Its major version is set to 1, and the expiration date is the current date.

How this sample works

This sample demonstrates how to define validators to check the content when Properties view cells are edited.

There are two types of validators:

  • One for a String property requestorEmail, to check whether the string is a valid email address.
  • One for the Integer properties minorVersion, majorVersion, and patchLevel to check whether the values are within bounds.

When you edit a property and its cell content does not match what is defined inside its validator, the Eclipse status bar displays an error message in the application window.

To redefine the default cell editors that are used in the Properties view for the custom properties, use the extension point in Rule Designer: ilog.rules.studio.ui.propertyEditors.

RequestorMailCellEditor class, in the package ilog.rules.studio.samples.customrulemodel.editors, extends org.eclipse.jface.viewers.TextCellEditor and provides a validator to check whether the cell content is an email address. The validator class implements org.eclipse.jface.viewers.ICellEditorValidator.

In this example, the RequestorMailCellEditor MailValidator inner class is the validator.

The validator provides a method, called isValid, that takes a Java™ object as parameter and returns the following responses:

  • A String that contains an error message if the content is not validated.
  • null when the cell content is validated.

You can edit the requestorEmail property of an Extended type rule to see the validator in action. If the cell content does not contain “@” or “.” characters, the Eclipse status bar displays error messages in the application window.

The same technique checks whether an integer is within bounds. ConstrainedIntegerCellEditor class, in the same package as RequestorMailCellEditor class, also extends TextCellEditor.

You can redefine some of the methods of TextCellEditor to work with integers: doGetValue and doSetValue.

This example reads the value of the boundaries from the property file data/boundaries.properties. Boundaries are retrieved on a class name basis. For each class, values are set as follows:

  • <class name>_LOWER_BOUND_VALUE
  • <class name>_UPPER_BOUND_VALUE

These values are read inside the cell editor validator class. The constrained properties (minorVersion, majorVersion, and patchLevel) get their implementation classes from ConstrainedIntegerCellEditor (abstract class).

You can add boundaries by creating an empty class that extends ConstrainedIntegerCellEditor, and by adding your lower and upper bound values inside the data/boundaries.properties file.

The CountryCellEditor class demonstrates how to dynamically change a list of possible values for a property. In this example, the drop-down list displays the names of the countries, but the value that is returned and persisted when an item is selected is a country code.

Redefining createControl() changes the combination box default behaviors and customization of doGetValue(), doSetValue(), and getItems() populates and sets the required values.

CountryCellEditor retrieves its value from an XML file. The current list depends the property region.

In ilog.rules.studio.samples.customrulemodel.propertyextension.MyPropertyExtension, which implements IlrPropertyExtension, a custom case in afterChange() resets the territory (selected country code) when you select another region.

You can use the MyPropertyExtension class to set a constraint on the date property effectiveDate. If the date does not match the predefined pattern, the status bar displays an error message.

The ilog.rules.studio.samples.customrulemodel.propertyextension.MyInitialValue is a callback class that implements the IlrInitialValue interface. The class is run when you set the expirationDate or the majorVersion properties for a new artifact. You specify the connection with these properties in the plug-in.xml file. For example: 

<extension
   id="ilog.rules.studio.samples.customrulemodel.initialValue"
   point="ilog.rules.studio.model.initialValueCallbacks">
   <initialValueCallback 
      id="BusinessRule.expirationDate"
      
callbackClass="ilog.rules.studio.samples.customrulemodel.propertyextension.MyIn
itialValue">
     </initialValueCallback>
   <initialValueCallback
      id="ExtendedRule.majorVersion"
      
callbackClass="ilog.rules.studio.samples.customrulemodel.propertyextension.MyIn
itialValue">
     </initialValueCallback>
</extension>

The extension point ilog.rules.studio.ui.propertyEditors sets the class that is associated with a rule model property. For example:

<propertyEditor target="ExtendedRule.minorVersion"
  
cellEditorClass="ilog.rules.studio.samples.customrulemodel.editors.MinorVersion
CellEditor">
</propertyEditor>

target references one property that is defined inside the rule model extension.

cellEditorClass references the class that is associated with the rule model property. This class extends the abstract class org.eclipse.jface.viewers.CellEditor or one of its children.

The extension point ilog.rules.studio.ui.propertyExtensions does custom actions on the rule properties cell editor events. For example:

<propertyExtension
  
propertyExtensionClass="ilog.rules.studio.samples.customrulemodel.propertyexten
sion.
  MyPropertyExtension">
</propertyExtension>

Source files

To display the source code of the customrulemodel sample plug-in:

  1. Click File  > Import.
  2. In the Import wizard, select Plug-in Development > Plug-ins and Fragments, and click Next.
  3. In the Import As section, select the Projects with source folders option, and click Next.
  4. In the Plug-ins and Fragments Found list, scroll down, select the ilog.rules.studio.samples.customrulemodel plug-in, and then click Add.
  5. Click Finish.
    Rule Designer imports the plug-in source code and displays it in Rule Explorer.
    Note: You can ignore the warning that the build path specifies execution environment JavaSE-1.7. You can also remove it by either installing Java 7 on your Rule Designer instance, or setting the execution environment of the sample plug-in to 1.7.
  6. Switch to the Plug-in Development perspective.
  7. In the Package Explorer, navigate to the Java source files.