AQLInterpreter: error finding variables otherwise available in Sirius-Desktop

[jadelkhoury]

• I have checked that this bug has not yet been reported by someone else
• I have checked that this bug appears on Chrome
• I have specified the version : latest
• I have specified my environment : my computer: Windows

Screenshots

In Sirius Desktop, I am using typical variables normally provided in the context of the action or representation I am programming. For example, when creating an element, I can use the "container" variable in my AQL code.
Similarly, when defining the Source Path Finder on an Edge element, I can make use of the "diagram" variable.

Example1: Action code upon Element Creation

Example2: Source Path Finder on an Edge

Expected & actual behavior

While these variables are available in Sirius Desktop, I get exceptions in Sirius Web when this same code needs to be executed.
For example,

2021-08-30 23:28:53.803 WARN 24312 --- [81-6784f7c74463] o.e.s.web.interpreter.AQLInterpreter : An error has occurred with the expression 'aql:diagram.containers->select(c | c.visible).target->select(c | c.oclIsTypeOf(adaptorinterface::Resource)).oclAsType(adaptorinterface::Resource)->select(r | r.resourceProperties->includes(self))': Couldn't find the 'diagram' variable
Besides "self" what variables are available for a given action? How can one work out what is available, and what is not. (In sirius desktop, I make use of the direct explanations in the interface).

This is similar to the closed issue #408, which was related to ElementView variable. I here have problems with other variables.

[pcdavid]

container variable

In the context of an diagram element creation tool, the container variable defined in Sirius Desktop is just an alias for the current element (self) at the start of the execution of the tool. We could define it, but for now there is only self. The thing is that from the screenshot, the place where you want to use the variable is inside a Create Instance operation, which will redefine the value of self.

I have not tested, but a workaround would be to wrap the body of your Container Creation tool with a Let operation to capture the initial value of self in your own variable, and use that new variable instead of container in the Set's value Expression.

I'm not really fond of the historical name container, which does not clearly indicate what it represents, but we could provide it as a compatibility feature for diagrams which are defined from an odesign file. I'll prepare a PR.

diagram variable

In Sirius Desktop, this variable points to a DDiagram element, which is the EMF-based data structure Sirius Desktop uses to represent diagrams. Sirius Web has its own, completely different and non-EMF data structure for this, and we do not want to expose it (it would become API and be very difficult to change/improve afterwards). It wouldn't be of much use to you anyway as it does not implement the same APIs at all.

In general, when people had to resort to using this "internal" model in their modelers it was often to workaround some limitations and/or to improve performance via "tricks". We'd rather directly support the higher-level use cases, and be fast enough that performance tricks like this are not needed.

Can you describe what your AQL expression tries to achieve functionnaly?

[jadelkhoury]

As a general background, my hope was to use the same odesign model for both desktop and web. I am willing to modify the model to suit both. But I wonder even this will be a realistic approach. I am aware that Sirius-web is still under development, but would be good to know already if this is a wise approach altogether.

Container variable

I have done some experiments now, and "container" is the same as self.econtainer() (not self).
but this can solve my problem, thanks.

diagram variable

I normally rely on the documented variables (see figure below) and didn't think these are internal. But granted, i could not expect a "diagram" to be available in Sirius-web. Anyway, I'll explain what I am trying to acheive. I will make use of UML to avoid the unnecessary specifics of our own domain language.

• Consider that I want to model inheritance between classes. If Class A is a sub-class of ClassB, I want to show an arrow from A to B.
• Now, each Diagram can represent one or more UML-Packages, within which the classes are graphically represented.
• My model consists of many such package diagrams.
• So, it is a likely scenario that a diagram contains a graphical representation of Class A but not ClassB (since ClassB is in another package that is not in the same diagram).
• In such a scenario, since there can be no arrow representation of this inheritance, I want to textually write "Class A extends ClassB" in the label of Class A.

For this to work, I needed AQL logic that can tell me which objects are visible. I believe this also worked in case the user happened to also "hide" some specific graphical elements.

diagram.containers->select(c | c.visible)

[pcdavid]

I normally rely on the documented variables (see figure below) and didn't think these are internal.

These were not technically internal (in the OSGi-sense for example), but they expose the implementation details of how Sirius Desktop represents diagrams, which makes them impossible (or at least very difficult) to evolve once people start (legitimately) to rely on them. We do not want to reproduce that mistake in Sirius Web.

I understand the use case, and it is valid. We could probably expose a higher-level Java service to answer the actual question you want to ask, i.e. something like "is the semantic element X represented somewhere on this diagram?". We'd need to think a little at the details to avoid creating something too specific to this particular scenario (so that over time we do not multiply ad-hoc services likes this).

A possible approach would be:

• in Sirius Web, expose a diagram variable, but make it an opaque object (not the actual Diagram data structure used by Sirius Web). On that opaque object, register an AQL service which corresponds to your use case (maybe generalized a little). Say for example represents(EObject semanticElement) (name to be discussed).
• in Sirius Desktop, we could register an equivalent Java service on the DDiagram type which is used there. This could be added directly in your own modeler definition until maybe it would be available directly into Sirius Desktop later on.

On your side, your odesign model could use a single expression like aql:diagram.represents(someSemanticElement), which would work the same in both Desktop and Web, just using different implementations underneath.

[jadelkhoury]

Hi

"is the semantic element X represented somewhere on this diagram?".

Another related question is also " "is the semantic element X represented somewhere within this "container!"?"." I am not sure if the 2 questions can be generalized into 1 service or not. But sometimes one want to also know if the element exists within a containing element.

Otherwise, the suggested approach looks good to me. Currrently, I have created my own Acceleo query to do this, because the current query is relatively complex.
For what it's worth, see the method visibleResources (diagram : DSemanticDiagram) which is then used to identify which specific elements are visible or not.
https://github.com/eclipse/lyo.designer/blob/5a48187cfded3310523ff56f8bf91788482736d7/org.eclipse.lyo.tools.toolchain.design/src/org/eclipse/lyo/tools/toolchain/design/domainSpecificationDiagram.mtl#L19

[pcdavid]

"is the semantic element X represented somewhere on this diagram?".

Another related question is also " "is the semantic element X represented somewhere within this "container!"?"." I am not sure if the 2 questions can be generalized into 1 service or not. But sometimes one want to also know if the element exists within a containing element.

Yes, there are probably useful variants depending on the context (the whole diagram or a particular container) and the kind or representation (to filter on mapping types). What's tricky is that even if we expose a pseudo "diagram" (which is really just an opaque handle), there is no way to denote other containers from an expression. And neither is there a direct way (except by name) to denote mappings.

The most general predicate which would cover all the cases would have this kind of signature:

isRepresented(what: semanticElement, where: diagram | container, how: child | borderNode, by: mapping)

These four properties being what uniquely identify an element on a diagram. But this is probably overkill for a first step, especially given that we do not have a good way for the specifier to denote containers and mappings.

AQL services support overloads, so starting with a much simpler version which only considers the diagram and semantic element would not prevent adding alternatives later. I'll have to think a little more about and maybe propose a first patch to discuss with the rest of the team. In particular, I'd like to see if such a service could be made efficient or if it will have to do a full walk on the diagram structure (which would be bad for an expression that can be invoked many many times during a single refresh depending on where it is used).

[pcdavid]

Reopening as the patch merged only solves one of the two issues.

I'll probably create a separate ticket for that, but in the meantime I'll reopen this so that the issue is not lost/forgotten.

[melaasar]

Hello. I also run into the missing 'diagram' variable issue above. In my case, I use the expression 'diagram.target' to know the model element that is the context of the diagram since such element is needed to calculate the label of a node. So, in the label expression of my node's style, "self" refers to the node's element, and "diagram.target" refers to the "context" element. Is there another service to get me the context element of the diagram in Sirius Web? In general, is there documentation of which services/variables are available in which context in Sirius Web (to help migrate desktop designers).