Views and Component
This chapter describes a detailed view of all elements used for modeling Views, Components or Shell.
Rich User Interface diagrams
Rich UI Diagram uses a custom Activity diagram to represent the UI. This diagram comes with a tool palette containing all basic widgets.
As HTML usually displays HTML in a flow layout, Rich UI diagrams are generated using two concepts: containment and order. This implies that all elements are either contained or have an order.
Note: The tagged value “order” is not required. If no order is provided, it will be generated in the UML creation order.
Shell, View or Component modeling
The UI modeling starts by defining a Shell (template page of the application) and a set of Views/Components.
Here is a generic composition:
- A Shell
- Views and Components containing.
- Controls and components
- Event Action definitions
Process Operation factorizes code into service or a reusable
operation in a View or a Component.
The shell represents the view which will contain all other views of the application. It must be unique within the entire model.
Creating the shell is just like creating a view, except that the stereotype to be applied is <<Shell>> instead of <<View>>.
The Shell is composed of presentation elements and one composition. A Composition defines parts which are redefined by views. This is done by creating a Structured Activity stereotyped <<Panel>> with the property "type=composition".
In order to catch exceptions on UI client model an Activity stereotyped <<UiException>> name and parameter are fixed and not generated. However the operation will always have one parameter “error” typed “any”. This Activity can only modeled once and must be placed directly under the package stereotyped <<PK_VIEW>>. This process supports service injection. However these services must have a global scope.
Component and View
Components are reusable UI parts, intended to be shared by the views. Views are UI parts, designed to be the user interface of a complete application use case; views are built using components and controls.
Components and views are very close in terms of modeling. What can be done for a component, can also be done for a view. The conceptual differences are a view can be reached via an URL or a navigation as a Component must be contained in a View. From a modeling point the view must always start with Panel/type=composition and the Component can start with any element. As a general rule both views and components must be contained in a use case.
When referencing a Component in a View the stereotype <<ComponentLayout>> must be applied as it contains additional information such as “order”.
Rich UI modeling has 2 main category of bindings:
- Static value bindings
- Domain model bindings
- Simple binding
- List binding
The stereotypes and tagged values are organized in hierarchy. By default all widgets stereotypes are inherited from <<UiBinding>> or <<UiBindingList>>. UiBinding binds single elements such as TextBox, Label, CheckBox, etc. UiBindingList is used for Data Grid, Select (drop down), Repeater, etc.
Domain model bindings always specify instances defined in the component (View, Shell or Component) to the widget. The component’s instance can be an Activity owned Property or a Parameter. I.e. see Figure 30 Instances in Data Grid/Repeater.
UiElement – static bindings
UiElement contains the list of basic properties. These properties are accessible on any widget and cannot be bound on instances.
|<<UiElement>> tagged value||Scope||Description|
|tabIndex||All||The tab order is the order in which a user moves focus from one control to another by pressing the TAB key. Setting a value of -1 will prevent the control from obtaining a focus.|
|order||All||Layout order, determine in which order the element are rendered.|
|text||All||Text property of the element.|
|styleClassName||All||Sets the CSS style class used by a control.|
|causeValidation||Panel||Sets a value indicating if the validation will be performed on any element that requires validation when it receives focus.|
|defaultValue||Form control (TextBox, Select, Radio Button, CheckBox, etc.)||Sets the default value of a control.|
|disabled||Form control||Disables a widget.|
|visibility||All||Renders or not a widget.|
|headerText||Widget connected to a Data Grid||Defines the header column. The widget needs to be a DataGrid.|
Table UiElement tagged values
UiBinding – data binding
UiBinding is used for simple controls or single value controls such as TextBox, Label, single CheckBox, etc.
|<<UiBinding>> tagged values||Type||Description|
|colProperty||UML:TypedElement||Name of the object property to which the element is bound.|
|instance||UML:TypedElement||Name of the instance to which the element is bound.|
|visibleProperty||UML:TypedElement||Defines the visibility state of the current component.|
|disabledProperty||UML:TypedElement||Defines the disabled state of the current component.|
|nestedProperty||String||Describes the associations path "." separated to the object containing the property to bind.|
|instanceDisabledProperty||UML:TypedElement||Name of the instance to which the enable state is bound.|
|nestedPropertyDisabledProperty||String||Describes the associations path "." separated to the object containing the disabled property to bind.|
|instanceVisibleProperty||UML:TypedElement||Name of the instance to which the visibility state is bound.|
|nestedPropertyVisibleProperty||String||Describes the associations path "." separated to the object containing the visible property to bind.|
Table UiBinding tagged values
UiBindingList – Data binding
UiBindingList is used for list type controls such as DataGrid, Select, Check Box, Radio Buttons, etc.
|<<UiBindingList>> tagged values||Scope||Description|
|value||Select, Radio Button, Check Box||Value bound to a list control (DropDown, CheckBox, RadioButton)|
|key||Select, Radio Button, Check Box||Identifies the label to display in a list element (DropDown, CheckBox, RadioButton)|
|selectedInstance||Deprecated?||Instance of the selected object from a control list.|
|listInstance||Select, Radio Button, Check Box, Repeater, DataGrid||Instance or property representing the list.|
|values||Select, Radio Button, Check Box||
List of allowed values, must be written in the specific format : <VALUE1>TAB<KEY1>/<VALUE2>TAB<KEY2>
Note: the property “values” is only available for Check Box, Radio Button, Select and Multi Select.
|instanceSelectedInstance||Deprecated?||Base instance to specify the selected instance property.|
|nestedPropertySelectedInstance||Deprecated?||Nested property for the selectedInstance property.|
|instanceSelection||Deprecated?||Base instance to define the selection property.|
|instanceListInstance||Deprecated?||Base instance to define the listInstance property.|
|nestedPropertyListInstance||Select, Radio Button, Check Box, Repeater, DataGrid||Describes the associations path "." separated to the object containing access to the listInstance property.|
|nestedPropertySelection||Deprecated?||Nested binding to access the selection property.|
Table <<UiBindingList>> tagged values
Specific binding rules: Grid and Repeater
When an element is connected to a Data Grid or contained within a Repeater, the instance should not be specified as it will be taken from the iterator value. In case the instance is specified it will override the iterator value. As shown below Figure 30 Instances in Data Grid/Repeater in green the instance is the Data Grid iterator value and in orange it’s an instance passed as a Parameter to the component.
Out of the box Widgets
Below is a complete list of all available widgets without any customization.
Widgets with binding capacity
List binding with object selection.
Note: In that case the property “value” is not specified.
|List binding with primitive value.|
List binding with static values
Note: In this case the widget “dpdVehicule” “colProperty’s” must be type=List as the widget allows multi selection.
Note: Inside a Repeater or a DataGrid, widget do not need to specify an instance unless it points to an instance outside of the repeated value.
Tableau 14 Widgets list with binding
TextBox are used to represent user input. They can be typed to accept different kind of inputs. Check browser capability to see if the type of inputs is supported.
|text||Standard text input.|
|password||User typed text is replace by *.|
|submit||Button submitting the form.|
|reset||Button resetting the form input values to their original values.|
|radio||Displays a “radio” button.|
|checkbox||Displays a “checkbox”.|
|color||User input displays a color. When user clicks it will open a color picker.|
|date||User input change to a date picker.|
|datetime-local||User input change to a date/time picker.|
|Will display a keyboard mail oriented on some device.|
|month||Displays a month picker.|
|number||Input will only allow number values.|
|search||Text input, it will apply different styles depending on the browser.|
|tel||Text input displays telephone keyboard depending on devices.|
|url||Text input check for a valid URL.|
|week||Displays week picker.|
Table TextBox types
Panels have 2 roles: containment and navigation (see chapter 5.8.3.) In its containment role it allows to define a “form” (in an HTML way), link or just simple panel. Panels also support bindings.
Data Grids display data in a grid. By default the grid support basic operations, more advanced operations such as filtering, order or line selection have to be done at the project level by either obtaining a third party library or by designing a component.
From a modeling perspective the DataGrid comes in two parts. The first part defines the grid’s own id and list instance. The second part represents the columns. The columns need to be connected to the grid definition using Object Flow as shown below.
If a column needs more than one component it needs to be contained in a <<DataColumn>>.
The chapter below describes the validation from a UI, data and behavior point of view.
In order to perform validation all widgets must be contained in a panel type form. Each form control must be contained in a panel with causeValidation enabled. From a CSS style perspective, we respect Bootstrap approach, which implies - when the container has the CSS “has-errors” - all children must behave accordingly. The validation is fired when form control is in a dirty state. Validation messages are displayed using <<Message>>/forId = [the form control].
Rich UI supports 4 types of validation: min, max, pattern and required.
|valMin||Minimum value, applies on text length|
|valMax||Maximum value, applies on text length|
|valRequired||True/False, specifies if the form control is required.|
|valMessage||Displayed message for the validation.|
Tableau 17 Type of validation
The validation behavior consists of enabling a control on success or setting up a condition in an event. In the sample below “appForm” is the form containing form controls.
In order to test the validity of a form in an event the “Form” control must be a property of the activity.
Navigation & Modules
Navigation is represented in a drill down approach. The application is broken into views and each view can imbricate a set of views. Breaking up the application in sub views allows navigation and the definition of modules.
Modules are autonomous functional unit and, from a packaging perspective, a module is bundled as a single file. Furthermore, those modules are loaded asynchronously.
In the model, navigations are defined with composition panels (a Structured Activity Node with <<Panel/type=composition>>). The shell must contain one composition panel, and the views must always start with a panel composition and may contain another panel composition in case they define another level of navigation.
Note: Modules are defined by Use Cases and sub compositions. It is a requirement that all sub navigation views are contained within the same Use Case.
In the example below we will obtain the following URL: http://foo.bar/viewa/viewc
We use the stereotype <<panel>>/type=composition to define modules and navigation throughout the application.
The Shell is the starting point for the navigation and it must contain a panel composition. This panel name is used in the view. It is possible to define default views for navigation by applying the stereotype <<START_VIEW>>.
Navigation URL parameters
Each navigation URL may contain a set of parameters. These parameters can only be primitive values and are defined on views as activity input parameters.
The example below will produce the following URL: http://foo.bar/multipleparameters/DefaultParameterOne/ParamTwo
This chapter focuses on how to access the widgets in Typescript. Widgets can be access with their properties bound to data in the Typescript class component or they can be accessed directly in the component class.
In order to access the widget in Typescript, the widget must be modeled in the activity as an Activity Node and as a property of the Activity. The property must be typed, Object being the default type.
Example on “appForm”:
In Rich UI, the view containing the login information (user & password) needs to be stereotyped <<LOGIN_PAGE>>. This allows the system to redirect to this page in case of authorization or authentication failure.
Roles definition & usages
Roles are represented by Actors and they must be contained in a package stereotyped <<PK_ROLE>>. These Actors can inherit from another Actor. The less secure actor is the most general. See the example below:
By default all REST end points are unsecured. Authorization is applied to Packages, Interfaces, and Operation by connecting an Actor with a dependency. Connecting Operations will override Interfaces and Interfaces will override Packages. Also when connecting an Actor to a package, all elements and sub packages contained will use that Actor/role.
Specific components or directive
Custom components or directives are supported by extending existing stereotypes from the Rich UI profile. Each “custom” stereotype must have “toTag” and each tagged value must have “to” stereotypes applied.
Note: All stereotype must be created inside a Profile Package.
|Stereotypes||Meta UML (applied to)|
Table Extensible stereotypes
Stereotype <<toTag>> for project components
The stereotype <<toTag>> is used to specify a custom component or a directive. The tagged value contains the component tag name, path and module name.
|toTag tagged values||Description|
|tagImplementation||Name of the component implementation. In Angular we use the module name.|
|tagName||Name of the tag i.e. “button-component”. This tag name will be used in the generated HTML i.e. <button-component …>|
Path pointing to the tag implementation.
Note: It must be an absolute path and does not start or end with a “/” i.e. “custom/button.component”
Note: For an external library the value see
Table <<toTag>> tagged values
Stereotype <<toTag>> for external libraries
External libraries can be used in Rich UI with the following constraint:
They must have a standard initialization.
They must be installable via Node Package Manager (NPM.)
The library must be referenced in the workflow dependencies and in the model as a Package with the stereotype <<elementsLibrary>> applied. The package name must be identical to the name of the library. Finally, this package will contain all stereotypes referencing the library components.
The stereotype <<to>> is used to specify the tag properties and must be applied on each tagged values.
|<<to>> tagged values||Description|
This tagged value manages the generation of the tagged value “to”. This allows the definition of static attributes or behavior in the generated tag.
Represents the generated property. It will always be generated as follows: value=”…”
Note: When using Angular you will need to respect the sugar template syntax see https://angular.io/docs/ts/latest/guide/template-syntax.html
Table <<to>> tagged values
In the example below:
“myDirective” has isHtmlProperty=false and will always generate.
“anotherDirective” has isHtmlProperty=false and will always generate.
“autoFocus” has isHtmlProperty=true and will generate when “autoFocus” receive a value.
A basic tag “BaseTag” which by itself does not do anything can be use when creating a Rich UI custom stereotype.
To extend a specific tag you need specific knowledge on the generated tag attributes. For example TextBox generates an “input” tag with the attribute “type”. Extending “TextBox” will change the tag name but all previous generated attributes will remain.