| Graphical Container with No Semantic Container [message #1303177] |
Sat, 19 April 2014 00:56  |
Eclipse User |
|
|
|
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 04:00  |
| Eclipse User |
|
|
|
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 #1384802 is a reply to message #1310541] |
Mon, 02 June 2014 03:57 |
| Eclipse User |
|
|
|
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.
|
|
|
Powered by
FUDForum. Page generated in 0.05268 seconds
Home