TAW12 - DEFINING THE USER INTERFACE (UI)

UI ELEMENTS

Graphical entities that occupy positions within a view layout are called UI elements.

The Label UI element provides a label to a particular field.

The TextView UI element helps you enter text.

The Button UI element is used to insert a button within a view layout.

The InputField UI element is used for inserting an input field to the layout. The Image UI element can be used to insert any image in the layout.

There are certain UI elements, such as theTransparentContainer, theViewContainerUIElement, or theInvisibleElement, which are not visible on the screen and are only used to structure the UI.

UI ELEMENT CATEGORIES

The elements for designing the user interface of a Web Dynpro application are divided into categories, which are displayed in the view designer:

  Text comprises elements that are used for displaying texts or entering literals.
  Action is the repository for simple elements that trigger navigation or just a round trip.
  Selection includes simple elements that display multiple values, from which the user can select one or more, depending on the element type.
  Complex lists elements that need subelements to define a valid UI element.
  Layout enumerates the UI elements used to structure the layout.
  Graphics groups elements to render graphical members of the page.
  Integration assembles elements that embed non-ABAP technologies in Web Dynpro

ARRENGEMENT OF UI ELEMENTS

Let us analyze the hierarchy of UI elements that constitute view layouts:

The root node, called RootUIElementContainer, is of the type TransparentContainer.

Additional UI elements in a view layout are hierarchically subordinate to RootUIElementContainer.

Context_Menu is the hard-coded context menu provider displayed above the RootUIElementContainer, which enables context menus to be defined at design time, and instantiated and assigned to UI elements. Hence, context menus can be defined statically as subelements of Context_Menu.

CONTAINER ELEMENTS: POSSIBLE CHILD ELEMENTS

Some UI elements may have arbitrary child elements.

We can identify a few examples of Container elements:

  Group
  Panel
  TransparentContainer
  Tray
  ScrollContainer (as this is deprecated, use TransparentContainer instead)

These UI elements occupy a rectangular area in a view’s layout and all UI elements that are children of a container element are located in this rectangular area.

UI ELEMENTS: LAYOUT PROPERTIES

All the container elements define the arrangement of their children with the Layout property, which assigns a layout manager to the container UI element. The Layout property may have five values:

  FlowLayout
  RowLayout
  MatrixLayout
  FormLayout
  GridLayout (instead, use MatrixLayout whenever possible)

LAYOUT MANAGERS: FLOWLAYOUT

The layout manager will have FlowLayout as the default selection. This ensures that all the child elements of a container are sequentially arranged. Therefore the line breaks cannot be specified explicitly.
Elements in different lines are not related to each other and this kind of container can be used to arrange subcontainers.
The container may be too narrow for the child elements to be displayed in one row. If the browser window is too narrow, for example, these elements are automatically wrapped to the next row(s).

UI ELEMENTS

If the container is wide enough, elements that do not force a line break are displayed in a row. If the container is too narrow for these child elements to be displayed in one row, they are automatically wrapped to the next row(s).

Some elements that do not force a line break are

  InputField;

  Label;

  FormattedTextView and TextView;

  Button, ButtonChoice, and ToggleButton;

  LinkChoice, LinkToAction, LinkToUrl, and ToggleLink;

  CheckBox and TriStateCheckBox;

  DropDownByIndex and DropDownByKey;

  RadioButton; and

  Image.

LAYOUT MANAGERS: ROWLAYOUT

If the layout property is set to RowLayout, then all the children inherit the property LayoutData, which contains the values RowData andRowHeadData.
A line break is forced if you set this property to RowHeadData.
If you set the property to RowData, no line break is forced.

LAYOUT MANAGERS: MATRIX LAYOUT

BIf you select MatrixLayout as the layout property, then all the children inherit the property LayoutData, which can have the values MatrixData andMatrixHeadData.

A line break is forced if you set the property to MatrixHeadData.
If you set the property to MatrixData, the child elements are displayed in the same row as the previous element, despite the right-hand margin appearing.
The child elements in this container are arranged in columns. The number of columns is defined by the maximum number of child elements in any row.

LAYOUT MANAGERS: GRIDLAYOUT

You can set the property to the GridLayout if you want a vertical alignment of the elements. The number of columns is defined statically by setting thecolCount property of the container element.
This kind of layout manager should be used if all rows have the same number of columns and if only complete rows are inserted or deleted.

LAYOUT MANAGERS: FORMLAYOUT ( 1 )

If you set the layout property to FormLayout, then all the children inherit the property LayoutData, which can have the values FormTopData,FormHeadData, and FormData.

With the setting FormTopData, you can divide the page horizontally in sections where each section contains a statically defined number of columns. The width of these columns is unique across all sections.

LAYOUT MANAGERS: FORMLAYOUT ( 2 )

You can force the line breaks by setting the property LayoutData property as FormHeadData.
The child elements are displayed in the same row as the previous element for the property set to FormData.
The spreading of the elements across the columns can be defined automatically if the colSpan is left at its default value (of -1).
If the colSpan value is set to n then the UI element is spread across n columns.

USING THE VIEW EDITOR

The View Editor is a Web Dynpro-specific tool that allows you to edit a view layout.
You can select the Change option from the context menu of a view to edit a view. The view editor can be used with or without the layout preview. The layout view will be selected by default.

VIEW EDITOR

By dragging any UI element from the toolbar on the left-hand side of the View Editor and dropping it in the layout preview, you can add it to the UI element hierarchy.
Alternatively, you can select Insert Element from the context menu of any superordinate element in the hierarchy that has child elements, such as aTransparentContainer element or a Group element to add a new UI element in the hierarchical representation.
The properties of a selected UI element can be changed or displayed by choosing the Properties tab. Properties with the prefix on relate to client-side events, examples being onFilter, onSort, or onAction. Actions have to be associated with each of these events.

DATA BINDING

The context data is used to supply a value to the UI element property if the UI element property is bound to a context node or attribute. Thus the data in the bound nodes and attributes are transported automatically to the corresponding UI elements.

PUTTING DATA ON THE SCREEN ( 1 )

Data binding necessarily defines a two-way relationship.
This two-way transport process is entirely automatic and requires no action on the part of the application developer.
The context attributes are first defined and declared in the CONTEXT.
Next, create the UI elements on the layout.
Finally, you bind the UI element to the context attribute.

DEFINING UI ELMENT PROPERTIES STATICALLY

You can either hard-code the value of a UI element property or bind it to a context attribute of a suitable data type. If, at design time, a property value is hard-coded, it only endows the UI element with a fixed behavior.

Accessing the UI element hierarchy directly from the controller’s method, however, is avoided. It is considered poor design, as flow logic and UI are no longer kept separate.

CONTROLLING UI ELEMENT PROPERTIES (1)

You might need to control the behavior of a UI element programmatically.
In this case,

  create a context attribute with a data type that matches the property you wish to control;

  choose the corresponding data type from the types available for each UI element property; and

  set the value of the attribute using the default value or any other method that accesses the attribute at runtime.

You can thus control the behavior of the UI element by modifying the related attribute value using any method of any controller that has access to this context attribute.

CONTROLLING UI ELEMENT PROPERTIES (2)

Once you create the context attribute, bind it to the appropriate UI element property. The example shows that the readOnly property of an InputField UIelement has been bound to a Boolean context attribute.
The value of the context attribute can now be manipulated by any controller hook method, or by your methods defined additionally.
You can bind the similar properties of multiple UI elements to the same attribute.

DATA BINDING FOR SAP NW 7.0 (ABAP SPS ≥ 12)

As per the SAP NetWeaver 7.0 SAP_ABAP support package stack 12, every context attribute permits you to bind not only the UI element’s primary property to it, but also the properties enabled, visible, readOnly, and state.
For the key property, you can select the radio button Bind Directly and establish a direct data binding.
If you choose the radio button Bind to the Property of the Selected Attribute, the properties enabled, visible, readOnly, and state can be bound to the corresponding context attribute properties, respectively.

COMPOSITE UI ELEMENTS (1)

Any UI element that requires a child UI element is known as a composite UI element.
Composite UI elements, such as Table and Tree, require complex mandatory child structures.

COMPOSITE UI ELEMENTS (2)

A composite UI element cannot display any information without the subordinate (or child) UI elements.
It must perforce have a child element to be able to function.
The slide depicts a hierarchical representation of a Table UI element.
FLIGHTTAB is considered a composite Table UI element. Its child UI elements are FLIGHTTAB_CARRID, FLIGHTTAB_CONNID, and so on.TableColumn elements are also considered composite UI elements.

THE TABLE UI ELEMENT

A good example of a composite UI element is the Table UI element. Its child element, the TableColumn UI element, is also a composite element. The Table UI element acts as a parent for several such TableColumn UI elements, each of which, in turn, acts as the parent for a header (Caption UI element) and a cell editor (TextView UI element).

BINDING A TABLE UI ELEMENT TO THE CONTEXT

Without context bindings, the UI elements of a Table cannot function correctly.
The Table UI element allows the two-dimensional display of data in cells arranged in rows and columns. It must be bound to a context node of cardinality0..n or 1..n.

TABLE COLUMN UI ELEMENTS

The Table UI element must contain at least one TableColumn UI element, which are also composite UI elements. There is no need to bind the TableColumn UI elements to the context nodes or the context attributes. The column header is created using a Caption element.

DEFINING CHILD UI ELEMENTS FOR A TABLECOLUMN

A TableColumn UI element must have a child UI element that acts as the cell editor. You can choose the child elements depending on the kind of interaction between the user and the data in each column.
The caption that appears as the column header is optional and is defined by the type Caption. The user cannot modify the data if you select a display-only UI element such as TextView.

TABLE ROW SELECTION

The example shows a node collection containing two elements. When the user clicks the second table row, element 2 of node FLIGHTS is activated. The lead selection of this node is then altered to reflect the user’s selection.
The number of rows in the table and the elements in the node collection are the same.

SELECTING MULTIPLE ROWS FROM A TABLE

The context node to which the Table UI element is bound must have a selection cardinality of either 0..n or 1..n, to enable the user to select multiple rows from a table.
The default selection cardinality setting for any context node is 0..1. This means that zero or one element may be selected at any one time.

SELECTION MODE: POSSIBLE VALUES

The Table UI element property SelectionMode has a default value as auto. This property can also be adjusted to none, single, multi, singleNoLead, and multiNoLead. These settings help mark rows and set the lead selection.
If selectionMode is set to none, the selection column is not displayed. The row related to the lead selection is not highlighted.
If selectionMode is set to single or singleNoLead, only one row may be selected. This is independent of the context node property Selection.
If selectionMode is set to singleNoLead or multiNoLead, the lead selection index is not changed by selecting table rows.

TEST PAGE FOR UI ELEMENTS

A Web Dynpro application WDR_TEST_UI_ELEMENTS is delivered in every system containing the Web Dynpro framework. This allows you to check out the various functions of the available UI elements.