...

• How the fields of a form must be positioned in the view (= the view / layout).

• Where to load and write the form model from / to.

• Where to load the /wiki/spaces/DEV/pages/2482176001 from.

• What to do, after a form has been submitted.

• Title, description, type and other settings of the form.

Here is an example of how such a form config could look like:

{
  "title": "Add person",
  "description": "Add a new person",
  "hidden": false,
  "schema": "$uri:property:global/app/tld.domain.myapp/object/person/v1/schema",
  "input":"$uri:property:global/app/tld.domain.myapp/object/person/v1/instance/67b07f3c-e006-4bec-a790-ef25b9fe97df",
  "output": "global/app/tld.domain.myapp/object/person/v1/instance/${vars.property.uuid}",
  "layout": {
    "orientation": "vertical",
    "items": [
      {
      "orientation": "horizontal",
      "items": [
        {
        "field": "firstName"
        },
        {
        "field": "lastName"
        }]
      },
      {
        "field": "age"
      },
      {
        "field": "gender"
      },
      {
        "field": "birthDate"
      }
    ]
  }
}

...

All form configs inside the form folder will be automatically picked - up and shown in the forms overview of an app. For example, here you can see the form Add person automatically listed:

...

The color of the form icon is used. If not givenspecified, the secondary color is used, which depends on the style settings. By default this is a blue color like this:

...

The color value can be a hex color hexadecimal value, like this:
"color": "#FFA500"

...

Another example:

"color": "red-8"

...

...

hidden

The schema This optional attribute defines a PIPEFORCE URI which is called in order to retrieve the Form schema for this form.

For example, the attribute could look like this:

"schema": "$uri:property:global/app/tld.domain.myapp/object/person/v1/schema"

Which could return a JSON schema like this:

{
  "type": "object",
  "properties": {
    "firstName": {
      "type": "string",
      "title": "First Name",
      "description": "The first name of the person."
    },
    "lastName": {
      "type": "string",
      "title": "Last Name",
      "description": "The last name of the person."
    },
    "age": {
      "type": "number",      
      "title": "Age",
      "description": "The age of the person."
    },
    "gender": {
      "type": "string",
      "title": "Gender",
      "description": "The gender of the person.",
      "enum": [
        "male",
        "female",
        "neutral"
      ]
    },
    "birthDate": {
      "type": "string",
      "format": "date",
      "title": "Date of birth",
      "description": "The date of birth of the person."
    }
  }
}

output

The output defines the path in the property store where the form data must be stored as JSON property after the form has been submitted. Example:

input": "global/app/tld.domain.myapp/object/person/v1/instance/${vars.property.uuid}"

The PE variable will be interpreted at server side and will be replaced by the uuid of the property.

The form handling pipeline can listen to a property.created event on this path then in order to get informed when a new property was created on this path:

pipeline:
  - event.listen:
      eventKey: property.created
      filter: ${body.target.path.contains('/tld.domain.myapp/object/person/v1/instance/')}

The same way it works with property.updated event.

Also see:

• https://logabit.atlassian.net/wiki/spaces/PA/pages/2545451358/Forms#The-Pipeline-(Controller)

input

The input attribute defines a PIPEFORCE URI which is called to retrieve the initial input data for the form in order to set predefined values on the form widgets. For example, the input parameter could look like this in order to load a JSON property from the property store:

"input": "$uri:property:global/app/tld.domain.myapp/object/person/v1/instance/fe97df"

Which could return a form data (= model) as JSON to be edited similar to this:

{
  "firstName": "Alice",
  "lastName": "Smith",
  "age": 20,
  "gender": "female",
  "birthDate": "2003/05/01"
}

forwardOnSuccess

This attribute defines an URL, or a path relative to the portal in order to forward to after the form has been submitted successfully. In case the submit caused an error, the form will stay at current location in order to display the error. In case this attribute is not given, the form will show the default submit success message.

onSuccess

This defines what should happen in case the form was successfully submitted. This is optional. If not defined, the default success message and icon will be shown:

forward

Forwards to a URL or a path relative to the portal. In case the submit caused an error, the form will stay at current location in order to display the error:

{
  "onSuccess": {
    "action": "forward",
    "url": "http://target/url"
  }
}

• action - must be set to forward.

• url - The URL or the path relative to the portal where to forward after success.

message

Shows a text message and an icon in case the form was successfully submitted.

{
  "onSuccess": {
    "action": "message",
    "text": "$uri:i18n:successMessage",
    "icon": "done",
    "color": "green"
  }
}

• action - Must be set to message.

• text - Can contain a static text or an i18n key. If not given, the default text will be shown.
  See: TODO

• icon - Must be a code name from the Google Material Icon. If not given, the default icon will be shown. See: https://fonts.google.com/icons .

• color - Defines the color of the icon. If not given, the default icon color will be shown.
  See Colors .

layout

By default, in a form, all widgets (= fields) of the Form Schema are displayed vertically, each ints own row.

...

Vertical orientation​

You can change this default by configuring orientation of the layout in the Form Config.

To do so, firstly you need to add the element layout to the form configuration as shown in this whether the form should be shown as tile inside the app ("hidden": false) or not ("hidden": true).

The form can be still loaded by its URL if required and used embedded in lists or workflows.

If this attribute is missing, "hidden": false is used as a default.

permissions

By default any logged-in user can see the the form using role based access rules (RBAC):

• RBAC-A: Is member of ROLE_DEVELOPER or

• RBAC-B: Is member of CAN_APP_<app.name> of the according app and ROLE_USER.

This is the default in case no permissions attribute is defined in the app config. This default can be overwritten by specifying the permissions attribute in the form config. In this case the RBAC-B will be ignored. Instead RBAC-C applies:

• RBAC-C: User is member of CAN_APP_<app.name> and at least one of the given permission rules is valid.

Example:

{
  ...
  "permissions": {
    "read": ["ROLE_GUEST"]
  }
}

The attribute read defines a list of permission strings the currently logged-in user must match at least one of. By default such a permission string is the name of a required role. In this example, any logged-in user assigned to ROLE_GUEST and CAN_APP_<app.name> is able to see this form. In case the user is assigned to ROLE_DEVELOPER he can also see this form since this will always apply.

PIPEFORCE URIs as permissions

Furthermore, also PIPEFORCE URI prefixes are supported to define permissions such as:

• $uri:group:<groupname> = Logged-in user must be member of group with name <groupname>.

• $uri:role:<rolename> = Logged-in user must have assigned this role (this is used by default also if no such prefix is used.)

Example:

{
  ...
  "permissions": {
    "read": ["ROLE_DEVELOPER", "$uri:group:supervisors"]
  }
}

schema

The schema attribute defines a PIPEFORCE URI which is called in order to retrieve the Form schema for this form.

For example, the attribute could look like this:

"schema": "$uri:property:global/app/tld.domain.myapp/object/person/v1/schema"

Which could return a JSON schema like this:

{
  "type": "object",
  "properties": {
    "firstName": {
      "type": "string",
      "title": "First Name",
      "description": "The first name of the person."
    },
    "lastName": {
      "type": "string",
      "title": "Last Name",
      "description": "The last name of the person."
    },
    "age": {
      "type": "number",      
      "title": "Age",
      "description": "The age of the person."
    },
    "gender": {
      "type": "string",
      "title": "Gender",
      "description": "The gender of the person.",
      "enum": [
        "male",
        "female",
        "neutral"
      ]
    },
    "birthDate": {
      "type": "string",
      "format": "date",
      "title": "Date of birth",
      "description": "The date of birth of the person."
    }
  }
}

output

The output defines the path in the property store where the form data must be stored as JSON property after the form has been submitted. Example:

"output": "$uri:property:global/app/tld.domain.myapp/data/person/"

Since path ends in a slash / the form framework identifies this as a new property creation and automatically appends the uuid of the new property as “filename” at the end of the path (since version 10). In versions < 10, you had to add the PE ${vars.property.uuid} at the end. This PE will be interpreted on the server side and replaced by the UUID of the property. This approach is deprecated and will be removed soon.

The form handling pipeline can listen to a property.created event on this path then in order to get informed when a new property was created on this path:

pipeline:
  - event.listen:
      eventKey: property.created
      filter: ${body.target.path.contains('/tld.domain.myapp/data/person/')}

The same way it works with property.updated event.

Also see:

• https://logabit.atlassian.net/wiki/spaces/PA/pages/2545451358/Forms#The-Pipeline-(Controller)

input

The input attribute defines a PIPEFORCE URI which is called to retrieve the initial input data for the form in order to set predefined values on the form widgets. For example, the input parameter could look like this in order to load a JSON property from the property store:

"input": "$uri:property:global/app/tld.domain.myapp/data/person/fe97df"

Which could return a form data (= model) as JSON to be edited similar to this:

{
  "firstName": "Alice",
  "lastName": "Smith",
  "age": 20,
  "gender": "female",
  "birthDate": "2003/05/01"
}

forwardOnSuccess

This attribute defines an URL, or a path relative to the portal in order to forward to after the form has been submitted successfully. In case the submit caused an error, the form will stay at current location in order to display the error. In case this attribute is not given, the form will show the default submit success message.

onSuccess

This defines what should happen in case the form was successfully submitted. This is optional. If not defined, the default success message and icon will be shown:

forward

Forwards to a URL or a path relative to the portal. In case the submit caused an error, the form will stay at current location in order to display the error:

{
  "onSuccess": {
    "action": "forward",
    "url": "http://target/url"
  }
}

• action - must be set to forward.

• url - The URL or the path relative to the portal where to forward after success.

message

Shows a text message and an icon in case the form was successfully submitted.

{
  "onSuccess": {
    "action": "message",
    "text": "$uri:i18n:successMessage",
    "icon": "done",
    "color": "green"
  }
}

• action - Must be set to message.

• text - Can contain a static text or an i18n key. If not given, the default text will be shown.
  See: TODO

• icon - Must be a code name from the Google Material Icon. If not given, the default icon will be shown. See: https://fonts.google.com/icons .

• color - Defines the color of the icon. If not given, the default icon color will be shown.
  See Colors .

layout

By default, in a form, all widgets (= fields) of the Form Schema are displayed vertically, each ints own row.

...

Vertical orientation​

You can change this default by configuring orientation of the layout in the Form Config.

To do so, firstly you need to add the element layout to the form configuration as shown in this example:

{
  "title": "Person",
  "description": "The person form",  
  ...
  
  "layout": {
    "orientation": "vertical",
    "items": [
      {"field": "firstName"},
      {"field": "lastName"},
      {"field": "age"},
      {"field": "gender"}
    ]
  }
}

This example layout configuration would create exactly the default layout again:

...

Horizontal orientation​

You can then change the orientation, width and height of a layout item like this:

{
  "title": "Person",
  "description": "The person form",  
  ...
  
  "layout": {
    "orientation": "horizontal",
    "height": "100",
    "width": "900",
    "items": [
      {"field": "firstName"},
      {"field": "lastName"},
      {"field": "age", "width": "150"},
      {"field": "gender"}
    ]
  }
}

The attributes width and height can be also specified on individual widget fields.

This would result in this form layout afterwards, where all fields are displayed in a single row (horizontally):

...

Width of 900 in horizontal layout item prevents fields to cover all of the available space.

In horizontal orientation, layout items and fields, by default, attempt to use maximum width while considering neighboring fields, making them responsive.

Both min-width and max-width can be also used in place of width to reach responsiveness within defined limits.

Nesting layouts and orientations​

Layouts and its orientations can be nested in order to create quite complex form structures. Here’s an example:

{
  "title": "Person Form",
  "description": "TheA simple person form.",  
  ...
  
  "layout": {
    "orientation": "verticalhorizontal",
    "items": [
      {"field
        "orientation": "firstNamevertical"},
        {"field": "lastName"},items": [
          {"field": "agefirstName"},
          {"field": "gender"}
    ]
  }
}

This example layout configuration would create exactly the default layout again:

...

Horizontal orientation​

You can then change the orientation, width and height of a layout item like this:

{
  "title": "Person",
  "description": "The person form",age"}
        ]
      ...},
     "layout": {
        "orientation": "horizontalvertical",
    "height    "items": [
          {"field": "100",lastName"},
          {"widthfield": "900gender",}
      "items": [ ]
     {"field": "firstName"},
}
    ]
  } 
 {"field": "lastName"},
      {"field": "age", "width": "150"},}

This example would produce a form with nested orientations like the one shown below:

...

field

Inside a layout element you can place field elements pointing to field ids (widgets). This element can contain additional attributes like these:

hidden

If set to true, the widget is not shown in the form, but the value from the input is sent to the backend on submit. Example:

      ...
 {"field": "gender"}    {
]   } }

The attributes width and height can be also specified on individual widget fields.

This would result in this form layout afterwards, where all fields are displayed in a single row (horizontally):

...

Width of 900 in horizontal layout item prevents fields to cover all of the available space.

Layout items and fields in horizontal orientation, by default, try to span as much width as possible, but with respect to neighbouring fields - behave responsively.

Both min-width and max-width can be also used in place of width to reach responsiveness within defined limits.

Nesting layouts and orientations​

Layouts and its orientations can be nested in order to create quite complex form structures. Here’s an example:

{
  "title": "Person Form",
  "description": "A simple person form.",  
  ...
  
  "layout": {
    "orientation": "horizontal",
    "items": [    "orientation": "vertical",
        "items": [
          {"field": "age", "hidden": true}
        ]
      },
      ...

readonly

If set to true, the widget value cannot be changed. Example:

      ...
      {
        "orientation": "vertical",
        "items": [
          {"field": "age", "readonly": true}
        ]
      },
      ...

height

Sets the height of this field, overwriting the default value in case the widget supports this attribute.

Example:

      ...
      {
        "orientation": "vertical",
        "items": [
          {"field": "firstName"}, "height": 20}
        {"field": "age"}]
      },
  ]    ...

width

Sets the width of this field, overwriting the default value in case the widget supports this attribute.

Example:

      },...
      {
        "orientation": "vertical",
        "items": [
          {"field": "lastNamefirstName"},           {"field"width": "gender"30}
        ]
      }
    ]
  } 
}

This example would produce a form like this with nested orientation:

...

field

Inside a layout element you can place field elements pointing to field ids (widgets). This element can contain additional attributes like these:

hidden

...

]
      },
      ...

color

In case this field is a multi-file upload, with color, the color of the file chips can be specified.

Example:

      ...
      {
        "orientation": "vertical",",
        "items": [
          {"field": "myFiles", "color": "blue"}
        ]
"items": [     },
      {"field": "age", "hidden": true}...

...

Grouping with title and border

If "border": true, a border is drawn around the current layout element.

If attribute title contains any value this is set as title of a group of the current layout element.

You will usually use both together to create a group of fields. Example:

      ...
   ]   {
   },       ...

readonly

If set to true, the widget value cannot be changed. Example:

 "orientation": "vertical",
    ...    "title":   {"Contact details",
        "orientationborder": "vertical"true,
        "items": [
            { "field": "age", "readonly": true} },
            { "field": "gender" },
            { "field": "birthDate"}
          ]
      },
      ...

This will produce a grouping with title like this:

...

type

TODO

Internationalization (i18n)

TODOThe title and description of a form and also its validation messages can be internationalized (= translated to different languages). See here for more details, how this works: Internationalization (i18n).

Special Form Types

Document Understand Form (with AI support)

TODO

Variable substitution

...

It is possible to use request parameters in the form config attributes as placeholders, like this:

"input": "$uri:command:workflow.history.tasks?taskId=${request.param.myTaskId}"

...