Package de.xima.fc.workflow.mixin

Interface IPluginConditionNodeHandler<TData extends BaseConditionProps>

Type Parameters:
TData - Type of the node's properties model, which must extend BaseConditionProps. The properties themselves are stored as JSON and serialized to / deserialized from this type automatically. You should make sure this type can be serialized / deserialized via JSON. This means you should only basic field types such as number, booleans, or strings, or nested types. Furthermore, if you wish, you can also use the type JSONObject to skip serialization / deserialization and work with the raw JSON data.
All Superinterfaces:
IBaseConditionClientHandlerNode<TData>, IBeanValidatingElement<TData,WorkflowNode>, IBeanValidatingNode<TData>, ICustomParametersUpdateable, IElementHandler<TData,WorkflowNode>, IExecutingLikeBinarySelectionNode<TData>, IExecutionResultDescriptor, IFCPlugin, IHierarchyValidatingNode<TData>, INamedUiElement, INameProviding, INodeHandler<TData>, IPluginGenericCustomGUI<IPluginWorkflowNodeBean>, IPluginWorkflowNode, IResourceBundleLocator, ISingleBaseConditionNodePrototype<TData>, ISingleElementPrototype<TData,WorkflowNode>, ISingleNodePrototype<TData>, ITransferable, IWorkflowElementTypeProviding, IWorkflowNodeFlowAnalyzer<TData>, IWorkflowNodeTypeProviding, Serializable
All Known Implementing Classes:
APluginConditionNodeHandler
public interface IPluginConditionNodeHandler<TData extends BaseConditionProps> extends IPluginWorkflowNode, INodeHandler<TData>, IBaseConditionClientHandlerNode<TData>, IBeanValidatingNode<TData>, IExecutingLikeBinarySelectionNode<TData>, ISingleBaseConditionNodePrototype<TData>
Mixin meant for IPluginWorkflowNode plugins that only wish to provide a workflow condition that checks a condition and redirects to the if or else branch based upon the result. The INodeHandler offers many methods that are irrelevant for this use case - this mixin implements most methods with the appropriate defaults.

By default, you only need to implement evaluateCondition(INodeExecutionParams) and getName(), as well as getPropertiesViewXhtmlName() for the UI. Make sure that the getName() is unique among all plugins. This name is also used as the getType() of the workflow node.

The XHTML page with the UI for editing the conditions's property must be placed in the directory getPropertiesViewXhtmlPath(), with the file name getPropertiesViewXhtmlName(). You can also add properties files in getResourceBundlePath() with localized messages for the UI.

Assume the getType() is MyConditionPlugin. Then, if you do not override the defaults:

  • For each language you want to support, add a properties file in /src/main/resources/WEB-INF/properties/i18n_LOCALECODE.properties. The LOCALECODE is en for English, de for German, fr for French etc. These properties are then available in the XHTML page via the variable msg, see IElementHandler.getPropertiesViewXhtml()
  • Add an entry in the properties file for the keys MyConditionPlugin.name, MyConditionPlugin.desc, MyConditionPlugin.label to customize the name of the plugin, the description of the plugin, and the name of the workflow condition.

You can also override most methods of this mixin to customize the condition plugin. The following lists a few common use cases:

To use a localized name or description
Add an entry to your getResourceBundle(Locale). For the name of the plugin as it appears in the backend plugin configuration menu, use getI18nKeyDisplayName(). For the description that also appears in the backend plugin configuration menu, use getI18nKeyDescription(). For the label of the action as it appears in the workflow designer, use getI18nKeyActionLabel().
To update the properties model for new versions of the plugin
First make sure the MANIFEST.MF of your plugin contains the appropriate version information, see getVersion(). Then, override ICustomParametersUpdateable.updateCustomParams(de.xima.fc.interfaces.IUpdateCustomParametersParams). If you are using the SemVer (semantic version) format (i.e. your version looks like x.y.z), you may want to use the default methods provided by the mixin ISemverUpdating.
To provide pre-configured conditions to the drawer panel to the left of the workflow designer
Override INodeHandler.getNodePrototypes(de.xima.fc.interfaces.workflow.params.IGetNodePrototypesParams), optionally adding the list of prototypes (which contains just one item) returned by the super method implementation.
To display the action in a different category in the workflow designer
Override ISingleElementPrototype.getSubCategory(IGetElementPrototypesParams)
To use a custom UI
Create an XHTML page in getPropertiesViewXhtmlPath(); and override getPropertiesViewXhtmlName() with the name of the XHTML page. For example, if you name the XHTML page myCustomUi and do not override the XHTML path, add the file /src/main/resources/WEB-INF/ui/myCustomUi.xhtml. If you need a custom bean as a controller, also override getMainPluginBeanClass(). See IElementHandler.getPropertiesViewXhtml() for more details on the XHTML page.
To use more than one bean
Override getUnmanagedBeans(), but make sure to include getMainPluginBeanClass(). The additional beans can be used in XHTML pages, or referenced via Inject.
To customize the serialization / deserialization process of the properties model
Use the JSONField annotation on the fields of your properties model class, and/or override IElementHandler.getFastJsonConverter()
Since:
8.0.0
Author:
XIMA MEDIA GmbH