Custom value editor sample details

You use Rule Designer to run this sample.

Running this sample

To test the custom value editor:
  1. In Rule Designer, open the offer rule in Value Editor Service/rules/computeOffer in the guided editor.
  2. Double-click #BFGHFDF in the condition part of the rule.

    The custom value editor opens:

    The custom value editor

    Use the text input field at the top to enter a case-sensitive pattern. When you enter a pattern, the list filters the entries. When you select an item, a window displays useful information to help you find the best match in the list.

    When you click OK or press Enter, the custom value editor closes and the new value is processed. However, if you press Esc, the custom value editor closes and the old value is kept in the rule.

    You can also access the custom value editor in the Intellirule editor:

    The custom value editor that is accessed from within the Intellirule Editor
  3. You can also use the custom editor in a decision table. Try it by editing the frequentBuyer decision table in the computeResult package.
Note: This customization feature is also available in Decision Center, except you use a web component instead of the Swing component in Rule Designer.

How this sample works

Open the purchase BOM entry in the Value Editor Service project and navigate to the PromotionalOffer class inside the sample package. A few custom properties are set on this BOM class.

Use the properties to do the following tasks:
  • Associate the custom value editor graphical component with the BOM class (valueditor).
  • Define how the data values that are managed by the custom value editor are processed, persisted, and represented in the rule editors, and how the value editor integrates with the rule editors (valueDescriptor and DecoratedValueDescriptor.prefix).
  • Define how the textual representation of the data values is converted in the rules (valueTranslator).

For information about how the custom value editor classes and extension points work, see the Source files section of this sample documentation.

To associate your custom value editor, descriptor, and translator with a BOM class, you set the custom properties:
  • valueEditor = sample.myeditor.editor: The key of the value editor extension.
  • DecoratedValueDescriptor.prefix #: Required to add a prefix to the value representation.
  • valueDescriptor sample.PromotionalOffer#Decorated(ilog.rules.brl.String): This example uses an existing value descriptor. To code a value descriptor, you must put the key of the value descriptor extension here, like for the value editor.
  • valueTranslator servervalueeditor.FilterValueTranslator: The key of the value translator extension.
    Note:
    • This sample uses a Swing based custom editor, but it is also possible to attach custom SWT editors inside the Intellirule editor.
    • This BOM and project form the basis of the corresponding sample in Decision Center. Therefore, Decision Center shares the IDs and class names with Rule Designer. For example, in valueTranslator, the value is a key for a Rule Designer extension point and a class name for Decision Center.
Tip: You can use a value info to associate a value editor with a BOM member. Value infos supersede value editors that are set on the underlying BOM class (see Extending BOM value types).

Source files

All classes for this sample are in the package ilog.rules.studio.samples.valueeditor, in an Eclipse plug-in with the same name.
  • The FilterValueEditor class extends ilog.rules.brl.ui.value.editor.IlrAWTValueEditor, which integrates the custom value editor in Rule Designer by extending the extension point ilog.rules.studio.model.brl.valueEditors.
  • The getValue and setValue methods handle communication between the Swing component integrated in the value editor and the rule editors.
  • The getEditorComponent method returns the Swing component that is used by the value editor. It is called each time that the component is displayed.
  • The FilterControl class is the Swing component class. The setValue and getValue methods do input and output operations in the Swing component.

    setValue passes an existing promotional offer code value, if any, which maps an element of the filter list.

    getValue occurs when you click OK or press Enter. It returns the new promotional offer code value to display in the rule.

    Depending on your Swing component, you can use any kind of method in place of the setValue and getValue methods to do the required input and output operations.

  • The FilterDataProvider class and its implementation, FilterDataProviderImpl, populate the value editor list and its item descriptions. You can use complex implementations that include XML or database integration.

The value descriptor transforms values between the rule text and the value editor component. It is required for representation and persistence.

This sample uses an existing value descriptor because the custom value editor works with simple values that can be converted to an existing String type (ilog.rules.brl.String). Note the prefix decoration: #.

You can also make a custom value descriptor by using one of these methods:
  • Create a class that implements ilog.rules.brl.value.descriptor.IlrValueDescriptor (or extend ilog.rules.brl.value.descriptor.IlrAbstractValueDescriptor) and reference the class in an extension of ilog.rules.studio.model.brl.valueDescriptors in your plug-in.
  • Make a new lexical representation of the “promotional offer code” in the rules (# "<promotional offer>"). You use this representation because Rule Designer uses regular expressions to persist, represent, and distinguish different types of values.

    Be careful to avoid lexical conflicts with other existing data types when you use regular expressions in your value descriptors (getParsableRepresentation method).

After you write your rule, you must associate a value translator with your data type (BOM class) so that Rule Designer can convert your rule into its IRL representation. In this sample, an extension of ilog.rules.studio.model.brl.valueTranslators in the plugins.xml file references the FilterValueTranslator class.

To make the extension work, FilterValueTranslator implements ilog.rules.brl.translation.codegen.IlrValueTranslator.

An instantiation of the sample.PromotionalOffer class converts the “promotional offer code” into IRL. You can examine the translateValue method.

To display the source code of the valueeditor Eclipse 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, select the ilog.rules.studio.samples.valueeditor plug-in, and then click Add.
  5. Click Finish.
    Rule Explorer displays the imported plug-in source code.
    Note: You can ignore the warning that the build path specifies execution environment Java™SE-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. In the Package Explorer, navigate to the Java source files.