Each user interface is a dynamic screen which changes its state depending on the users action. Due to this, each modeled user interface screen is assigned to a <<UIState>> of a State Machine model. The State Machine model not only holds the <<UIStates>> but also defines the interaction between the different screens using <<UITransitions>>.
|
|
The State Machine Model works as a controller orchestrating not only the screen flows but also the handling of events. Furthermore, the State Machine, being the controller of the views, links the invocation of the services with the UI views.
| The first step is to create a new Repository Navigation below the UI node within the containment tree. |
| The State Machine is held by a <<UI>> class. To create this UI create a class within the Navigation package and apply the stereotype <<UI>> to it. |
| On the <<UI>> class create a State Machine Diagram. The name of the diagram will be taken from the <<UI>> parent node. |
Each state which has a user interface attached to it needs the stereotype <<UIState>>. The following properties are available to be set:
| Property | Description |
|---|---|
Template | This property is the link to the state's user interface. The template consists of the root element of the screen e.g. Panel. |
Is Modal Dialog | This option influences the behavior of the user interface. If this option is set to true, the dialog window opening will be the most front window and needs to be closed before being able to do any further action on the main application page. |
Call On Entry | Specifies a <<JavaScript>>operation to be called. |
Call On Exit | Specifies a <<JavaScript>> operation to be called. |
Service Call On Entry | This property can be used to call a SOAP service when the screen is loading. |
Service Call On Exit | This property can be set to call a SOAP service when the screen is left. |
| For each of the two screens add a <<UIState>> to the State Machine Diagram and link the states to the screens. |
The interaction between the user interfaces are modeled using <<UITransitions>> between the <<UIStates>>. The <<UITransition>> offers the following parameters to be set:
| Property | Description |
|---|---|
Event | The Event defines which action was done by e.g. the click event is caused by a user clicking on an OK button (click is also the default). |
Event Source | With the event source you define the user interface element which triggers the event. |
Event Bubbling | Event Bubbling is an event delegation mechanism that allows you to bind an event handler to a target node of a DOM structure. That event, if fired, will be propagated to its ancestor nodes until it reaches the root element. Consider a handler on a HTML form tag that reacts on any changes made to any of the form elements to trigger a change in displaying information or saving content. |
Animation | Some web browsers allow some animated transitions from one state to another. For example, all browser support fade in and fade out. But for instance, flipping and sliding is supported by WebKit based browsers only (e.g. Safari). |
Service Call | This refers to the SOAP operation being called when an event has been triggered. |
Call | Specifies a <<JavaScript>> operation to be called (expert mode only). |
Time Out | Specifies the time how long the event should wait. It is specified in seconds. |
| Connect the HelloWorld State to the Confirmation State using a <<UITransition>> and amend the parameters as following: This <<UITransition>> is going to be triggered when the changeTextButton button is clicked and leads to the Confirmation State. |
| The modal confirmation dialog has two buttons (YES and NO) of which only the YES button will trigger the event that will change the default Label text. The NO button will exit the Confirmation State and close the dialog window. Add a <<UITransition>> from the Confirmation State to the HelloWorld State. Amend the transitions parameters to the following: |
| Now add another <<UITransition>> from the Confirmation State to the HelloWorld State and set the event to click and the event source to noButton. Clicking the NO button will not trigger any service or script call so no further parameters need to be set. |
Accessing Data Outside The State Context
When input data is set on a page it is not necessarily persisted and will get lost as soon as a browser refresh is done, the browser window is closed or the page is changed without sending or processing the data. As most applications consist of more than one page that mostly share data, it is essential to know how data can be shared between different views.
In the HelloWorld example the input data is held by the main HelloWorld user interface state 1. The next step in the application flow opens a modal dialog window. This is following the <<UITransition>> from the HelloWorld State to the Confirmation State 2. This modal dialog window does not know about the data in the main user interface 1 due to leaving the actual context of the HelloWorld State. In case the user clicks on the Yes button in the confirmation dialog 3, it is possible to call the changeHelloWorldText operation 4 but due to not being in the context of the main HelloWorld State anymore, where the users input data is residing, the operation will fail to change the text. It is missing the users input.
The solution to the problem of loosing the context is to bind the input data to a global variable. A global variable is a parameter which is defined directly on the <<UI>> class and holds a value globally within the <<UI>>s context. This means this variable can be accessed from any user interface belonging to the <<UI>> class. In the HelloWorld example, the global variable is the myText parameter as shown in the figure below.
This variable needs to be bound to the data itself, being either a text input field (as in this case) or a different source. The next chapter will demonstrate how the binding of this global variable is done for the HelloWorld example application.
On this Page:
Overview
Content Tools