Input dialogs

If more than one simple confirmation is required, input dialogs are used. This allows you to provide the user with one or more text boxes to fill out.

An attribute is defined for each text box. Similar to the object definitions (objectTypes.xml), there are several attribute types available for the individual requirements of the text boxes. You can add validators (<validator>) to these attributes, for example, to limit the scope of the attribute by restricting the number of characters or figures that can be entered in an text box. The names of the XML elements result from the name of the attribute type, that is, <booleanAttribute>, <longAttribute>. You should use naming conventions for the IDs of the attributes, thus facilitating working with the collected data of the dialog. That means, when you transfer an attribute from a dialog to an object, both attributes should have the same name. For example, when create an object, the attribute of the environment selection in the client_sign dialog should have the same name as the corresponding attribute of the object to be created.

Existing attribute types

boolean

Attribute for Boolean values (Yes/No).

date

Attribute for date values.

double

Attribute for floating point numbers.

enum

Attribute for enumerations (enumerations_*.xml).

long

Attribute for integers.

selection

Attribute for selecting values from a predefined dynamic list, for example, when selecting an environment. PredefinedValueProvider is available to define the possible values of the selection list. The application contains some of these configurable providers (see below). But you can also implement some providers manually.

string

Attribute for simple text text boxes. Content and length of the text can be limited.

text

Attribute for texts consisting of several rows.

There are several PredefinedValueProviders for the selection attribute. They can be parameterized and provide different possibilities.

Existing PredefinedValueProviders

client

Provides a list of all environments that the user has access to. This list can be limited by a maximum of one of the following parameters:

  • componentRight

    Only outputs environments for which a specific componentRight exists (roles.xml).

  • objectRight

    Only outputs environments for which a specific objectRight (roles.xml) exists for the current ObjectType (defined by the objectTypeId parameter).

  • licensedComponent

    Only outputs environments that have a specific licensed component.

Additional parameters:

  • objectTypeId

    ID of an object type (objecttypes.xml) that for example, is set by the createObjectDialog command. This parameter is only required in connection with the objectRight parameter.

static

Manages a list of elements defined previously in Java code.

usergroup

Outputs a list with available user groups.

Parameter:

  • client_sign

    Determines which environments the groups should be limited to if clientDependent=true. This parameter can also be defined dynamically by another attribute of the dialog (see the loss_create dialog).

  • roles

    A comma-separated list of role names (roles.xml). Only groups with the corresponding roles are considered.

  • clientDependent

    Determines whether environment-specific (true) or cross-environment (false) groups are searched for (Default false).

view

Uses a view (views_*.xml) to create a list with elements. The parameters value, id and client require the IDs of the corresponding columns in the view as values.

In the following example a new dialog is created, which is displayed when creating a new control. Some attributes of the control are queried and then set in the newly created control.

Location

XML file in the xml folder

Procedure

  1. Define a new <dialog> element with a unique ID.
  2. Add an appropriate subordinate attribute element to each attribute in the dialog. See the text above for possible attribute types.
  3. Assign an ID to each attribute type. If the input values should be transferred directly to the attribute of an object, they should both have the same ID, for example, client_sign (see also objectTypes.xml). Every dialog and each of its attributes result in the corresponding property keys dialog.<dialogID>.DBI, attribute.<dialogID>.<attributeID>.DBI).
  4. Create a new <form> element. The ID of the form is inherited from the dialog ID DIALOG_<dialogID>. Currently such forms consist of exactly one <page> element with a single <rowGroup> element.
  5. For each attribute, add a <row> element with an <element> element to the rowGroup. The XML attribute id (row) and attribute.idref (element) refer to the corresponding ID of the dialog attribute.
  6. Adapt the corresponding commandchain of the object (see previous chapter).

Documents

dialogs.xsd, forms.xsd, dialogs.xml, forms_*.xml

Example

AddNewInputDialog

\WEB-INF\config\custom\xml\custom.xml: Add custom dialog