Forms

Concept

A form uses an extended version of JSON Schema to define a form.

Form Development

Additional patch-mechanisms used when developing forms for modules

Version Determination

See the timestamp section on the page about modules.

JSON Representation

{
    "forms": {
        "93e7aab7-7fee-4b87-b038-e893dbf6dc44": {
            "name": "Simple Form",
            "definition": "classpath:/de/ecm4u/faw/module/simple/forms/simple-form-1.0.0.json",
            "module": "simple-1.0.0"
        }
    }
}

The JSON representation of a task has four properites:

  • UUID: The JSON object is keyed by the UUID that identifies the form.
  • name: The name of the form.
  • definition: The of the form. This can be an inlined JSON object or a classpath URL to a JSON file.
  • module: The module version in which the form fast first included.

Form Definition

A form consists of five parts: schema, form, uiSchema and actions.

{
    "schema": {},
    "form": [],
    "layout": [],
    "uiSchema": {},
    "actions": {}
}

Schema

The schema defines the data model of the form fields.

{
    "schema": {
        "properties": {
            "description" : {
                "type" : "string",
                "required" : true,
                "default" : "Enter your description here ..."
            }
        }
    }
}

Form

The form defines the visibility and order of form fields.

{
    "form": [
        "description"
    ]
}

Layout

It is possible to put form elements into rows. The optional layout array contains an object for every row.

{
    "layout": [
        {
            "properties": ["review_state", "approve_state"],
            "columns": [6, 6]
        }
    ]
}
  • properties: The names of the form properties that shall be put into a row together.
  • columns: The relative widths of the properties (must add up to 12).

uiSchema

The uiSchema allows more specific configuration of the form fields. Dependending on the intended behaviour of the form field, a specific combination of options can be used.

See the documentation for the supported widgets.

Actions

Actions can be used to add behaviour to form elements. You can add an action to a form element that belongs to a form property. Or you can add buttons that do not correspond to form properties.

Save Action

If the action ist save, the widget, when its value is changed, triggers a save and reload of the complete form. If the Flow or Task Instance the form belongs to has the property save-form-script, the referenced Nashorn script is executed on the FaW server after save and before reload.

This example defines a number widget with this behaviour.

{
    "schema": {
        "properties": {
            "myNumberProperty": {
                "type": "string"
            }
        }
    },
    "form": [
        "myNumberProperty"
    ],
    "uiSchema": {
        "myNumberProperty": {
            "widget": "number",
            "digits": 2
        }
    },
    "action": {
        "myNumberProperty": "save"
    },
    "formData": {
        "myNumberProperty": 1234.56
    }
}

On Change Action

If the action ist onChange, the widget, when its value is changed, triggers a named Action Script to be executed on the FaW server. The complete form is rebuild after the action execution has finished.

This example defines a mdhEntity widget that, when its value is changed, triggers the named Action Script partner-changed on the FaW Server.

{
  "schema": {
    "properties": {
      "bd_partnerNo": {
        "minItems": 0,
        "type": "string",
        "required": true,
        "enum": []
      },
    }
  },
  "form": [
    "bd_partnerNo"
  ],
  "uiSchema": {
    "bd_partnerNo": {
      "widget": "mdhEntity",
      "idProperty": "id",
      "displayProperty": "{id} ({displayName})",
      "searchProperty": "displayName",
      "multiple": false,
      "source": "BusinessPartner",
    }
  },
  "actions": {
      "bd_partnerNo": "partner-changed"
  },
  "formData": {
    "bd_partnerNo": "BP-1234"
  }
}

On Click Action

You can also bind an action to a form element that does not belong to a form property. You will have to define the form element in the form section and reference it in the action section.

This example will render a button that, when clicked, executes the exand-inbound Script Action on the FaW server.

{
  "schema": {
    "properties": {
    }
  },
  "form": [
    {
        "id": "expand-inbound-btn",
        "type": "button"
    }
  ],
  "actions": {
    "expand-inbound-btn": {
        "onClick": "expand-inbound"
    }
  }
}

formData

The formData part is optional for the creation of a form as it mainly contains the chosen values. Nevertheless it can be important for script/action usage, e.g. to pre-set fields.

I18N

When a form instance is displayed, labels are added to each field, as section headings, as input field placeholders, and as button texts. The values for these labels are defined in JSON textresource files having type=i18n. I18N textresources are loaded first for the flow instance, second for the task instance the form instance belongs to. The labels loaded for the task instance override thos loaded for the flow instance. This makes it possible to define lables that apply to all tasks in a flow to a common textresource.

An example for a I18N JSON file:

{
    "de": {
        "sin_state": "Rechnungsstatus",
        "fieldset_optional_information": "Optionale Informationen",
        "comments_placeholder": "Kommentar eingeben ...",
        "add-link": "Nebenzuordnung hinzufügen"
    },
    "en": {
        "sin_state": "Invoice State",
        "fieldset_optional_information": "Optional Information",
        "comments_placeholder": "Enter comment ...",
        "add-link": "Choosen an optional Assignment"
    }
}

The file must contain a JSON object. The keys in this object are locales, the values objects with the lable values for this locale. The above example defines label values for two locales, de and en.

The keys in a lables JOSN object are:

  • form property IDs: sin_state
  • fieldset IDs: fieldset_optional_information
  • input field placeholders: comments_placeholder
  • action button IDs: add-link

Inside a form JSON, they correpond to the locations illustrated in the following abbreviated example.

{
    "schema": {
        "properties": {
            "sin_state": {
                "readOnly": true,
                "type": "string",
                "required": false
            }
        }
    },
    "form": [
        {
            "id": "fieldset_optional_information",
            "expandable": false,
            "type": "fieldset",
            "items": [
                "sin_state",
                {
                    "placeholder": "comments_placeholder",
                    "type": "textarea",
                    "key": "comments"
                },
                {
                    "id": "add-link",
                    "type": "button"
                }
            ]
        }
    ]
}

Save formData values

A Form Instance can be configured to automatically save values from formData on save or submit. There are two ways to configure this feature.

Parameters of CreateFormInstanceAction

The CreateFromInstanceAction supports four parameters to define the formData values to be saved.

Configuration Service

The formData values to save can be put into the Configuration Services. The subjects are

  • taskInstancePropertiesOnSave
  • taskInstancePropertiesOnSubmit
  • flowInstancePropertiesOnSave
  • flowInstancePropertiesOnSubmit

The key is the name of the Form Instance. The value must be a comma separated string containing the names of the formData properties.