Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Sirius » Graphical Container with No Semantic Container(Group elements in a diagram dynamically )
Graphical Container with No Semantic Container [message #1303177] Sat, 19 April 2014 04:56 Go to next message
Nikolay Manolov is currently offline Nikolay ManolovFriend
Messages: 15
Registered: June 2012
Junior Member
Hi All,

Another beginner here happy to have found this project!

I looked through the forum and have found this topic which is somewhat relevant to my problem/question.
http://www.eclipse.org/forums/index.php/t/645292/
There it is discussed how to create (sub)containers which are not directly represented by a semantic element. How is it done? They just map the main (diagram/tree) container and the subcontainers to the same semantic element and filter what elements are shown in which container.
So if the metamodel looks like this
class Field

class Group{
   Field[] headFields
   Field[] tableFields
}


we can visualize the model as this
Group
    SubGroup_HeadFields
        Field1
        Field2
    Subgroup_TableFields
        Field3
        Field4


Please don't get confused if I mix the terms. The example above talks about a treeview, whereas in my case it is about a diagram, but the same logic applies.
So above, Group and the two SubGroups are defined in the specification and are all mapped to the the class Group.

My question is would it be possible to have a dynamic number of containers based on some attribute value of the Fields. Say I have the following metamodel

class Field
   String type

class Group{
   Field[] fields
}


I want my representation to have a subgroup for each unique value of Field.type among all existing Fields. The problem here, in contrast to the previous example, is that I do NOT know in advance all of the subgroups as they are determined by the user input (model).

Group
   SubgroupForFieldType="Fruit"
      Field_Apple
      Field_Wattermellon
   SubgroupForFieldType="Car"
      Field_Ford
      Field_BMW
   SubgroupForFieldType="Whatever..."
      ...

Re: Graphical Container with No Semantic Container [message #1310486 is a reply to message #1303177] Wed, 23 April 2014 08:00 Go to previous messageGo to next message
Pierre-Charles David is currently offline Pierre-Charles DavidFriend
Messages: 146
Registered: July 2009
Senior Member
Le 19/04/2014 06:56, Nikolay Manolov a écrit :
> Hi All,

Hi.

> My question is would it be possible to have a dynamic number of
> containers based on some attribute value of the Fields. Say I have the
> following metamodel
>
> class Field
> String type
>
> class Group{
> Field[] fields
> }
>
> I want my representation to have a subgroup for each unique value of
> Field.type among all existing Fields. The problem here, in contrast to
> the previous example, is that I do NOT know in advance all of the
> subgroups as they are determined by the user input (model).
>
> Group
> SubgroupForFieldType="Fruit"
> Field_Apple
> Field_Wattermellon
> SubgroupForFieldType="Car"
> Field_Ford
> Field_BMW
> SubgroupForFieldType="Whatever..."
> ...

From a quick look it does not seem possible, sorry. Normally graphical
elements on a diagram must be bound to an element in the model to
identify them (along with their type and context), but in your case the
identifying "key" is an attribute value, and not full blown EObject.

A trick that may be possible in some cases, but has its own issues, is
to use one of the element of each group as an identifying element for
the whole group, and associate e.g. SubgroupForFieldType="Fruit" to
Field_Apple. For this to work you must be able to write an expression
that, from a Group, returns a single element for each of the groups you
want to have (say, Field_Apple and Field_Ford in your case). But this
has important limitations: the expression must return the same
identifying element each time it will be evaluated by Sirius. If you do
something like "group by type, sort by name and take the first of each
group", some changes in the model (elements renamed, added, removed)
will result in a different element used a a key for the group. Sirius
will interpret this as "old group removed (with all its contents), new
group added (with new equivalent content)", and all layout information
on the old group will be lost in the new one.

If you control the metamodel and if it is not too impacting, you can
create a reified type (i.e. an explicit EClass) to represent the group
keys, and a derived feature in Group, say EList<GroupKey>
getGroupKeys(), with GroupKey an EClass with a single EString attribute.
It would work, but it would be a shame to "pollute" your model with
concepts irrelevant to your domain just to please a specific tool.

Anyway, that's the current state of affairs. It's not the first time we
are confronted with this (or similar) issues, maybe we can think of a
better solution to directly support these cases. Could you open a
bugzilla about this?

Regards,
Pierre-Charles David
Re: Graphical Container with No Semantic Container [message #1310541 is a reply to message #1310486] Wed, 23 April 2014 08:43 Go to previous messageGo to next message
Nikolay Manolov is currently offline Nikolay ManolovFriend
Messages: 15
Registered: June 2012
Junior Member
Hi,

thanks for the info!

Actually I was playing around the last few days and ended the up with exactly that solution. I did not know how to make an expression so I wrote a service. Is it actually possible to write an OCL expression that can group elements by some attribute and return the first one for each group?

Anyways my service is a bit more complicated because I also want to group the elements by connections as well. In general some of the elements have the same attribute value and the same connections, but they might have the same attribute value and different connections. So I would like in addition to grouping them in a container to visualize only one set of connections connected to the container and not the elements themselves. That should work fine I am guessing.

Since I am using a service perhaps it would be possible to sort by object id (instead of a name attribute), which persists until the element is deleted? That should be a bit more robust.

I guess I will open a bugzilla. It seems like a useful feature for visualization to be able to put elements in a diagram that are not defined by a class but can still be derived from the model via an algorithm.
Re: Graphical Container with No Semantic Container [message #1384802 is a reply to message #1310541] Mon, 02 June 2014 07:57 Go to previous message
Nikolay Manolov is currently offline Nikolay ManolovFriend
Messages: 15
Registered: June 2012
Junior Member
Just a quick update. I have thought some on the issue and ended up not opening a bugzilla.

In the described case it is more appropriate to have a dedicated class for the type and not just an attribute. In which case I would have an element to map to.
Furthermore it is possible to create a container with the described method. And a class to map to is probably always needed if you want to have functionality associated with the container.
Previous Topic:[gsoc2014] Tool groups/sections creation by refactoring
Next Topic:Drag&Drop without moving the Node ...
Goto Forum:
  


Current Time: Fri Dec 19 02:22:42 GMT 2014

Powered by FUDForum. Page generated in 0.01805 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software