Data binding for views

Binding a view to a business object creates an association between data and a user interface for it.

To associate a business object and a view, you bind the view to the business object. When the view definition declares a binding type, you must bind the view to data. Without the data that is provided by the binding, the view might not function properly. When the view definition does not declare a binding type, the data binding is optional.

For example, you have an Address business object. To display one or more parameters of that business object, you create a view. You then add the Address business object as a variable to that view. The Address business object now has an associated view. Although a business object can have an association with many views, a view can have only one binding. For example, the Address business object can have an associated view that displays all the address information. It can also have an association with a different view that displays just the postal code.

Tip: Alternatively, in the Process Designer, you can create a view directly from an existing business object. The business data of the new view is bound to the business object it originated from. See Developing reusable views.

When a business object is associated with a view, you can drop the parameters of the business object onto the layout. These parameters are available as variables on the palette. If there is a view that is associated with that data type of the variable, the layout displays that view. For example, if you drop a string onto the layout, you can see a Text view that is bound to the string. If the variable is a business object that has an associated view, you can see that view. If the business object does not have an associated view, you can see a placeholder message.

If the variable is a list, what you drop onto the layout determines the view that Process Designer adds to the layout. You can change the view that the designer selected.

If the variable is a primitive data type, such as a string or one parameter business object, Process Designer adds a Select view.
If the variable is a business object with more than one parameter, Process Designer adds a Table view with a column for each parameter. Each column contains the view that is associated with the data type of the variable.
If you drop a currentItem variable onto the layout, Process Designer adds a vertical section that contains the view that is associated with data type of variable. At run time, the content of the section repeats for each item in the list.
If you drop a listSelected variable onto the layout, Process Designer adds the view that is associated with the data type of the variable. At run time, the view contains the data for the selected item in the list. For example, you have a Select view that is bound to listBO[] and an Output Text view that is bound to listBO.listSelected.myItem. At run time, the user selects the third item in the Select view. The Output Text view displays the third myItem string.

When you have a view definition that contains a Content Box item and an instance of that view is bound to a list, the contents in the content box repeats for each list item. The content box can contain views that are also bound to lists or elements of lists. When you have this arrangement, the list of the container (outer) view controls the repetition. The list of the contained (inner) view provides the contents. For example, you have a section that is bound to a list of names. The content box for the section contains a Text view that is bound to the currentItem of the list of names. At run time, the section repeats for each name in the list. Each repeating section contains a field. In the first section, the field contains the first name. The field in the second section contains the second name, and so on.

You can bind the outer view and the inner views to different lists. However, if you bind an inner view to the currentItem of a different list, the two lists must contain the same number of items. If the two lists do not have the same number of items, users see a message. The specific message depends on whether the inner list contains more or fewer items. If the outer list has more items, the users see some highlighted views in the repeated content. They are highlighted because they do not have data. For example, outerList[] has three items and innerList[] has two items. The views that are bound to innerList.currentItem repeat three times, but only the first two have data. If the outer list has fewer items during run time, the user cannot see these excess items because the inner list has nowhere to display them. For example, outerList[] has four items and innerList[] has five items. The views that are bound to innerList.currentitem repeat four times. The user cannot see the views for the fifth innerList[] item.