This page explains how to configure the main logic of your RichUI application.
This section describes the minimum package requirement for any Rich UI model. Each project must have one <<PK_TARGET>> containing a <<PK_VIEW>> as shown below :
Note: Any element outside of PK_TARGET is ignored by the generator.
Each View, Component or Shell must be contained in a package stereotyped <<PK_VIEW>> and in a UseCase. See below in blue package <<PK_VIEW>> and in green the UseCase containing views.
The application may contain only one Shell and multiple Views and Components. Views, Shell or Components must have stereotypes <<View>>, <<Shell>> and <<Component>>. Views must start with a <<Panel>> type=composition and the Shell must at least contain one <<Panel>> type=composition.
Logic & Behavior processes
This chapter covers a set of basic rules for modeling client logic. There are 3 types of process to represent application logic: Service, Event and View/Component Functions.
Note: In Angular generation, services are injected and their instantiation is managed using provider.
Services and events processes
Services are defined with interfaces directly containing activity diagram stereotyped <<ProcessOperation>> which represents the code logic. Services can also own properties like classes.
Events are Activities defined within a View/Component or Shell stereotyped <<EventAction>>.
Process Operation are Activities stereotyped <<ProcessOperation>>. They can be defined within a View, Component or Shell:
Scopes define how to instantiate services. These services can be instantiated for a View/Component or the entire Application. In order to change the scope we apply a stereotype on Interfaces as follow:
|None||Service is instantiated at the component level.|
|application||Service is instantiated at the application level.|
|static||Service is not instantiated. This case is useful for third party services.|
Table Service scope's stereotypes
View, Component or Shell Events
Rich UI events are represented as Activities. The link with the widget is done by creating a Call Behavior Action on the View/Component/Shell diagram. The Call Behavior Action's name must equal the widget name. Events can be broken in 2 types: component life cycle and component behavior. In order to model an event you will need to create an activity and the first parameter will define the type of event. Finally, model the logic as standard Activity Diagram.
|EventOnLoad||Life cycle||Fires before the component is loading. Do not need to be added as a Call Behavior Action.|
|EventConstructor||Life cycle||Fires when the component is instantiated. Do not need to be added as a Call Behavior Action.|
|EventActivated||Behavior||Fires when component receive focus.|
|EventLeave||Behavior||Fires when component lose focus.|
|EventChange||Behavior||Fires when the view model of the component has changed.|
|EventClick||Behavior||Fires when the component is clicked.|
|EventDoubleClick||Behavior||Fires when the component is double clicked.|
|EventKeyDown||Behavior||Fires when the component has focus and a key is down.|
|EventKeyPress||Behavior||Fires when the component has focus and a key is pressed.|
|EventKeyUp||Behavior||Fires when the component has focus and a key is up.|
|EventRowClick*||Behavior||Fires when a Data Grid row is clicked.|
|EventRowDoubleClick*||Behavior||Fires when a Data Grid row is double clicked.|
|EventRowKeyDown*||Behavior||Fires when a Data Grid row has focus and a key is down.|
|EventRowKeyPress*||Behavior||Fires when a Data Grid row has focus and a key is pressed.|
|EventRowKeyUp*||Behavior||Fires when a Data Grid row has focus and a key is up.|
Table Component Events
Note: (*) Will be present in a future release of Rich UI.
REST End points
REST interfaces or end points are modeled under <<PK_SERVICE>> package. They are defined by interfaces stereotyped <<JsonController>> and operations stereotyped <<JsonService>> with <<process>>. By default operation with input parameter are done in HTTP POST and operation with no input are in HTTP GET. Only one input and output parameter is permitted.
By default, it is necessary to add <<@Transaction>> stereotype to a model operation so it is generated as transactional. A workflow option exists, named autoTransactionManagement. If set, the above mentioned <<JsonService>> stereotype will imply transactionality of the backend method. This enables the usual use case where one would like all the endpoint methods to be transactional.
It is still possible to use the <<@Transaction>> stereotype in order to setup isolation level, for instance, through dedicated tagged values.
By default mappings are calculated from the package stereotyped <<PK_SERVICE>> and concatenating the workflow variable "restPath". However the mapping can be overridden when using the tagged value "mapping" on stereotype <<JsonController>>. If the operation is not stereotyped <<process>> it won't be generated and if the interface does not contains any operation stereotyped <<process>>, the Interface is not generated.
Input parameters consist of multiple primitive objects and only one complex object (a class). While primitive parameters are interpreted as path variable, the complex object is interpreted as request body. The return parameter can be of any type. If the an operation has a complex objet it will generate an HTTP POST operation otherwise it will be HTTP GET.
Activity diagram are used to represent code logic. They must start with an "Initial Node" and always end with a "Final Node".
Parameters are defined on Activity and must be typed. We support two types of direction "in" and "return". Keep in mind return type are not required.
General rule for EventAction modeling and ProcessOperation:
For Process Operations no parameter are required.
For Events at least one type is required and it must be typed with a class <<TypeEvent>>.
Note: <<EventType>> classes are coming from the Rich UI profile and they are not customizable.
Each Call Action Node can only have one incoming Control Flow and one outgoing Control Flow.
Note: Input Pin and Output Pin must have a parameter synchronized as the graphical representation of Pins in diagram do not represent the order of parameters. If a Pin has no Synch Element (linking the Parameter) it might result in not generating the call operation correctly.
Call Operation Action
Code will generate differently depending on the operation stereotypes or the type of container.
|If the class operation bears one of these stereotype, it will generate a property. Otherwise it will generate an operation call.||Call Operation must be connected to a Central Buffer Node representing the instance using an incoming Object Flow.|
HTTP REST call
|The service instance is automatically generated.|
Table Call Behavior Action
Call Behavior Action
Call Behavior Action represents either a simple navigation or a call to an operation.
|ProcessOperation||Operation call||The service instance is automatically generated.|
|View||Navigation call||This navigation is always relative. For more advanced navigation, you will need to model a specific API call.|
Table Call Behavior Action
Opaque Actions generates their body content as is unless the language is set to "bags" - see below.
Central Buffer Node
Central Buffer Node are used to define instances. If an operation call is not a service (represented by an Interface), the Call Operation Action must have an incoming Object Flow from the Node to the Call Action.
BAGS is a DSL representing code expression. They are modeled in bodies of Opaque Action or in guard as a Literal String Expression with language set to "bags". BAGS manages simple statements such as: assignments, logic expressions and call operation. If an expression is too complex it should be done using standard process modeling or a simple Opaque Action.
As a general rule all instances present in a BAGS must have a representation. For example "a == b", a & b must be represented as a Central Buffer Node or a Parameter.
Note: In BAGS the generator will detect if the instance is a local variable or a class member. It will add "this" automatically.
|a = b||a = b|
|a = b + "5"||a = b + '5'||In java script it transform double quotes into single quote.|
|a.prop = b||a.prop = b|
|a = b.prop||a = b.prop|
|a.prop = b.prop + c.prop||a.prop = b.prop + c.prop||Complex assignments|
|a == b||a === b|
|a != b||a !== b|
|a > b||a > b|
|a < b||a < b|
|a >= b||a >= b|
|a <= b||a <= b|
"a" must be declared as a Central Buffer Node.
"TypeA" a type must be stereotyped <<constant>>.
"TypeA" must be declared as a nameless Central Buffer Node.
"TypeA" a type must be stereotyped <<constant>>.
|a = @StringUtils.function(...)||a = this.stringUtils.function(...)|
|Class Model operation call|
|myVal = @$instance.isFunc()||a = instance.isFunc()||"instance" needs to be declared as Central Buffer Node or a Property.|
Table BAGS Operators & function sample
BAGS Operators support
Below is a list of supported operators:
Arithmetic operators are supported except increment and decrement.
Relational operators are fully supported.
Bitwise operator are not supported.
Logical operator are fully supported.
Assignment operator support only '='.
In BAGS utility functions must start with "@" followed by the service name. To represent a call operation modeled in a Class the symbols "@$" must be present before the class instance.
Note: In Typescript utility functions will generate the import and the constructor injection. The folder containing utility functions is defined by the workflow variable "bagUtilPath". By default its value is set to "services/". These functions need to be modeled as standard Rich UI Process.
Expansion Region are used to represent iterations. The type of iteration is determined by the Expansion Region Node type. The iterator is represented by an Expansion Node Variable. The Expansion is treated as a sub diagram it must start with an Initial Node and end with a Final Node.
Typed array iteration.
Note: Variable type must of the same type as the array/list.
Note: Variable type must be a number type.
For in statement
Note: The variable type must always be typed "String".
Table Types of Expansion Region Node
Decision & Merge Nodes
Conditions are represented by outgoing Control flows containing a guard coming from a Decision Node. Each outgoing Control Flow from a Decision Node must have an equivalent incoming Control Flow on a Merge Node. If multiple outgoing Control Flow are modeled, they must have a "weight" which will determine the generation order.
Note: Empty conditions are not generated. If a Control Flow is directly connected from a Decision Node to a Merge Node, it will be skipped.