UI DSL
The platform independent DSL “UI” defines module types, element types, member types and options to describe user interfaces. The DSL isn’t specialized on certain classes of devices (e.g. mobile). A UI model defines nothing else than the structure of a user interface (without any sizes or colors), its content and its binding to data sources.
Here is a list of all provided types.
| Module-Types | Element-Types | Member-Types |
|---|---|---|
| Ui | comp | none |
| Ui | display | component |
| Ui | databinding | none |
| Ui | container | none |
| Ui | layout | none |
| Ui | toolbar | component |
| Ui | flow | none |
| Ui | application | none |
| Ui | storage | none |
| Ui | interfaces | none |
In the following, each type is going to be described in detail.
Module-Types¶
Ui¶
Example:
...
module MyModule kind = Ui;
...
Options for Module-Type “Ui”
| Option | Option-Type | Description |
|---|---|---|
| no options defined | - | - |
Element-Types¶
comp¶
A “comp” element is used to define a user interface component, like a button or a text field. Please note that “comp” defines a user interface component whereas “component” (see further down) defines the usage of a “comp”.
Example of a button definition:
...
comp Button;
...
Options for Element-Type “comp”
| Option | Option-Type | Description |
|---|---|---|
| no options defined | - | - |
display¶
A “display” element is ued to define a user interface area, where user interface components can be displayed. You can for instance use a “display” to define an input form or a selection list.
Options for Element-Type “display”
| Option | Option-Type | Description |
|---|---|---|
| no options defined | - | - |
Members and Member-Options for Element-Type “display”
Member: component
A “component” member defines the usage of a user interface component, that previously has been defined by means of a “comp” element.
| Option | Option-Type | Description |
|---|---|---|
| Label | Quoted Text | The value defined here is used as the default label for the user interface component. Typically, a generator follows the rule: When there is a “Label” defined, then there is automatically the usage of a label component generated for the usage of the component. |
| EntityField | Reference, single valued | References a “field” of an “entity” element. This defines a direct data binding, which is a sepcialization of the implicit data binding, that can be modeld by means of “display” and “databinding” elements. |
databinding¶
A “databinding” element allows you to group several “display” elements and link those to an “entity”. This means, the linked “entity” provides the data for the “display” elements.
Options for Element-Type “databinding”
| Option | Option-Type | Description |
|---|---|---|
| Containers | Reference, multi valued | Lets you group a set of “displays” in order to use that grouping for data binding (linking it to an entity) |
| Entity | Reference, single valued | This option lets you assign an “entity” to a group of “displays” (through the databinding element). |
container¶
A “container” is the common parent element of “layout”, “display” and “toolbar”.
Options for Element-Type “container”
| Option | Option-Type | Description |
|---|---|---|
| Abstract | Boolean | A “container” that is set to be “Abstract” serves as a parent container of other, concrete child containers. |
| Title | Quoted Text | A “Title” defines a standard text, that can be used as panel title, section title or a similar part of a user interface component. |
| Children | Reference, multi valued | With the help of the “Children” option, you model a tree of user interface containers. |
| Toolbars | Reference, multi valued | “Toolbars” lets you link modeled “toolbars” with a “layout” or “display” container. With this, you define a set of actions, that can be taken for a certain area of a user interface (e.g. save, open, delete, reload). |
layout¶
With a “layout” you structure a user interface. Styles (pixel sizes, colors, …) are not going to be modeled.
Options for Element-Type “layout”
| Option | Option-Type | Description |
|---|---|---|
| Orientation | Enumerated, single valued | Possible values: TopToBottom, LeftToRight Defines the direction in which the child “container” elements are layed out inside the “layout”. |
| Type | Enumerated, single valued | Possible values: Split, Tab Defines, whether the child “containers” are positioned on top of each other (Tab) or next to each other (Split). |
toolbar¶
A “toolbar” groups actions that a user can take.
Options for Element-Type “toolbar”
| Option | Option-Type | Description |
|---|---|---|
| no options defined | - | - |
Members and Member-Options for Element-Type “toolbar”
Member: component
A “component” member defines the usage of a UI component, that previously has been defined as a “comp”. Within a “toolbar” the UI components that are used typically are buttons, links or menu items.
| Option | Option-Type | Description |
|---|---|---|
| HasIcon | Boolean | If this option is set to true, the generated usage of a UI component leads to the display of an icon on the component. |
| Label | Quoted Text | With “Label” you define a default text, that is then placed on a UI component, e.g. a button. |
| EntityField | Reference, single valued | References a “field” of an “entity”. The “field” holds the data that is going to be displayed by the “component”. |
flow¶
A “flow” element defines, how you get from one user interface container to another.
Options for Element-Type “flow”
| Option | Option-Type | Description |
|---|---|---|
| Type | Enumerated, single valued | Possible values: Open, Replace, Push Defines, in which way a new user interface container is going to be opened.
|
| From | Reference, single valued | “From” sets the user interface container, from where the navigation starts. |
| To | Reference, single valued | “To”sets the user interface container, where the navigation ends. |
| Components | Reference, multi valued | With “Components” you define, which user interface components (e.g. a button) trigger the navigation. |
application¶
With an “application” element you model an application. It serves as the entry point to all other elements of a UI model.
Options for Element-Type “application”
| Option | Option-Type | Description |
|---|---|---|
| DefaultLanguage | Text | A language code, to set the default language of the application. For example de for German or en for English. |
| OfflineCapability | Boolean | When OfflineCapability is set to true, then a generator knows, that it has to generate code, that allows to work with the application even when there is no permanent network connection. |
| Root | Reference, single valued | An element of type “container”. Defines, which user interface container is going to be displayed first, when the application is started. Please note that an application splash screen normally is not meant by this. |
| Storage | Reference, multi valued | One or more elements of type “storage”. Defines where and how application data is managed. Options that are set for the referenced “storage” element provide the information for a generator, to generate sensible code to manage application data. |
| Menu | Reference, multi valued | One or more elements of type “toolbar”. With this you can define a global menu for the application. |
| Interfaces | Reference, multi valued | One or more elements of type “interface”. Here you can define how to access a remote service, for example a REST-API. It is the “interface” element that holds the relevant information for a generator to know what to generate. |
storage¶
A “storage” element nominates persistence modules, that define data structures to be used by the application.
Options for Element-Type “storage”
| Option | Option-Type | Description |
|---|---|---|
| Type | Enumeration, single valued | Possible values: Local, Remote Defines, where the application data comes from. “Local” means on the same computer, where the application is executed. “Remote” means from a different computer that is accessible over the network. |
| Modules | Reference, multi valued | One or more persistence modules (“module” with kind=Persistence). The modules contain the data structures for the application data. |
| Entities | Reference, multi valued | One or more “entity” elements, in case you do not want to use complete persistence modules to describe the application data structures. |
| EntityFields | Reference, multi valued | One or more “field” elements, in case you do not want to use complete entities to describe the application data structures. |
interfaces¶
An “interface” element references modeled function modules (“module” with kind=Function). Those function modules relate to parts of a software that can be accessed across process boundaries. A generator typcially creates code that handles the calls to the remote services.
Options for Element-Type “interfaces”
| Option | Option-Type | Description |
|---|---|---|
| Modules | Reference, multi valued | References one or more function modules. Those modules represent remote services, no matter whether those have been generated or developed manually. |
| Functions | Reference, multi valued | deprecated |