Skip to main content
aboutsummaryrefslogtreecommitdiffstats
blob: a362efbc4b22eb1a7474fa6e26dc6fffef29fe98 (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
h2. Page

h3(#description). Description

The page is the first concept directly related to the user interface that you will manipulate. It will contain or reference everything displayed in the user interface. Using the Sirius integration, each page will create a new tab in the Properties view.

h3(#properties). Properties

* identifier: This property is used to identify the page, it is used by the EEF runtime in order to find out if the user interface must be recreated from scratch or if it can be reused during a change of selection.
* labelExpression: The label expression is used in order to compute the label of the page. Using the Sirius integration, this expression will be used to compute the label of the tab in the Properties view. This expression must return a string.
* domainClass: The domain class is used in order to determine if the page can be used for the current input. If the page uses a domain class, it will only be displayed if the current input is an EObject with an EClass which directly matches the domain class or with one of its superclass matching the domain class.
* semanticCandidateExpression: The semantic candidate expression is used to select the object that will be used as the current context of the page. It allows you for example, to use an object as the input of the view but then decide that in a specific page, you want to display the properties of another object. This expression must return one object or a collection of objects to be used as the new context of the page. More information are available below in order to create multiple pages from one definition.
* preconditionExpression: The precondition expression is used in order to determine if the page should be displayed or not. This expression must return a boolean.
* groups: The list of the "groups":group.html that should be used in this page.
* semanticValidationRules: The validation rules of the page. For more details regarding the validation in EEF, have a look at the documentation of the "validation":validation.html.
* actions: The list of the Toolbar Actions used to create buttons in the toolbar of the page. Those actions can contain a tooltipExpression wich should return a string used as the tooltip, an actionExpression executed when the user will click on the button and an imageExpression used to configure the appearance of the button. The imageExpression must return a string with the following structure PROJECT_NAME/IMAGE_PATH, for example: org.eclipse.sample/icons/Icon.gif

h4(#variables). Variables

The semantic candidate expression will have access to two variables @self@ and @input@ from the view. The result of the semantic candidate expression will be accessible as the new context in the variable @self@ for the other expressions of the page and the concept under the page.

The label expression and the precondition expression (along the expressions in the semantic validation rules) will have access to both the variable @input@ and the variable @self@ which will now contain the value of the semantic candidate expression of the page.

h3(#multiplepagesfromonedefinition). Create multiple pages from one definition

If you have a very complex meta-model, you cannot possibly create the definition of your user interface widgets after widgets. In order to handle those situation, you need more powerful mechanisms. Using the same approach and vocabulary as Eclipse Sirius, you can create in EEF several pages from a single definition using the semantic candidate expression.

The goal of the semantic candidate expression is to let you determine which object will be used as the context of the page. By default, if you do not specify the semantic candidate expression, we will reuse the input of the view. As usual, in our examples we will use expressions based on AQL, with this in mind, not specifying a semantic candidate expression is the same as using @aql:self@. In the semantic candidate expression, the variable @self@ is the input of the view.

You could also change the current object used in the page by using the expression @aql:self.anotherObject@. You could type pretty much any valid expressions to navigate to another object but with this mechanism you can also create multiple pages from your semantic candidate expression if this expression returns a collection of objects instead of one object.

If you use the expression @aql:self.otherObjects->select(object | object.isValid())@ as the semantic candidate expression, you will create one page for each object returned by your expression. This way, you can have a simple definition which will be able to handle dozens of elements in your domain.

Back to the top