Comment 1 Parsa Pourali 2016-04-09 22:31:41 EDT

Created attachment 260818 [details]
Screen shot of the Context

Comment 2 Parsa Pourali 2016-04-09 22:31:59 EDT

Hi,

When using direct label edit on an element in the diagram, it would be good if Sirius could return the diagram element such as containerView. This is possible for a delete action but not for direct label edit.

As a Scenario, consider we have a nested containers and we are editing the label of a node in the innermost container. Now, I can't have access to the outermost container. All I can access is the self variable which is the semantic element.

(See Attachment Please)

Thanks,
Parsa

Comment 3 Laurent Fasani 2016-04-14 04:00:43 EDT

Hi Parsa

In my opinion, if changing the semantic element label has a consequence to the representation element, it should be handled when refreshing.
So, as an additional information, and to measure the right level of priority to this ticket, could explain why you need to get the representation element such the outermost container.

Thanks

Comment 4 Parsa Pourali 2016-04-14 11:31:47 EDT

Created attachment 260957 [details]
Scenario screen shot

Comment 5 Parsa Pourali 2016-04-14 11:44:58 EDT

Hi Laurent,

Let me give you an example :)

Consider the following Xtext pseudo-grammar:

System:
   (features=[Feature])* (messages=[Message]);

Feature:
   messages+=[Message] ; //this message should be defined in System messages

Message:
   name=ID attributes=[Attributes]

...

Based on the above grammar, we define messages in the System and refer to the defined messages in our features. I have added an screenshot for this scenario in the attachments.

So, assume we have enable() message in the system, and features F4, F5 and F6 use/refer to the enable() message. So, we have three containers for the features and in each of these container we have a node that shows the enable() message.

F4_container {enable()_Node}
F5_container {enable()_Node}
F6_container {enable()_Node}

Now, if a user renames enable()_Node in the F4_container to disable(), it will rename the original enable() message in the System (because it is a reference object). Therefor, we will have the followings:

F4_container {disable()_Node}
F5_container {disable()_Node}
F6_container {disable()_Node}

However, at this time I need to ask the user if they want to propagate the change to all the features or not ? If the user says "no propagation", then I need to somehow do the rename operation only for the feature that they have asked. This is the moment that I need to get the F4_container() and only change the message name for F4 (by creating a new message named disable() ). Unfortunately, currently I can't have access to the selected container.

For now, I could manage doing it by creating a transient (one to one) attribute like below:

System:
   (features=[Feature])* (messages=[Message]);

Feature:
   refmsg=[RefMessage];

refMessage:
   messages+=[Message] ; //this message should be defined in System messages

Message:
   name=ID attributes=[Attributes]


and then I associate each message node with refmsg and show the message attribute as the label. This way since refmsg is only for its container feature, I have access to the parent feature.

I hope this clarifies the situation.

Thank you,
Bests,
Parsa

Comment 6 Maxime Porhel 2016-04-26 05:32:22 EDT

Hi Parsa, 

This enhancement would allow to be more consistent in the tool definition: like in the delete tool, a containerView or elementView variable could allow to get information about the currently edited diagram view, its mapping, its container hierarchy or the edges connected, ...

IMO, it is not containerView but elementView which is needed. The elementView variable would reference the view from which we want to edit the label.

But you need to be aware that you must not edit the name of the view: it is computed from your VSM. So you must modify your semantic model and then Sirius will refresh the label from the semantic state.

So this variable will just allow you to retrieve information like: 
 . which view element is selected/edited, 
 . retrieve the mapping of the edited element
 . retrieve the container or the diagram (the containerView variable is not required as it is simply elementView.eContainer().
 . count or retrieve the edges views, the children views, ... if there is no semantic relation, or if you want to simplify your requests as Sirius already did the job to build the view model from your VSM. 

Note that we have currently not planned to work on it in the following releases.

Comment 7 Maxime Porhel 2016-04-26 06:15:17 EDT

Parsa,

For your modeler, I wonder if you should replace this direct edit (and even  forbid it on the Feature sub elements) by an other kind of interaction lile a double click, a menu or a selection wizard. 

In a Feature container, you are displaying Messages which are defined in the System and which can be referenced form other features, so renaming a message means changing its name, not changing the referenced message. 

Instead of creating this RefMessage, I would propose to disable the direct edit on messages displayed in Feature containers (as they are shared and referenced between the Features) and to have a specific diagram or bunch of tools to edit/create the message. You might have a tool to create a new message by clicking on a Feature and (pane based) selection wizards to click on a Feature and manage their messages.