Eclipse Community Forums: GMF (Graphical Modeling Framework) » Derived feature as containment feature

Help

Home

Home » Modeling » GMF (Graphical Modeling Framework) » Derived feature as containment feature

Show: Today's Messages :: Show Polls :: Message Navigator

Derived feature as containment feature [message #230302]

Thu, 14 May 2009 15:22

Antonio Navarro Perez

Messages: 5
Registered: July 2009

Junior Member

Hi,

I'm working on a graphical editor for a domain model which has the
following basic structure:

http://www.rolleyes.de/pub/GMF_DomainModel.png

Both Component and VirtualComponent have a 0:* compartment reference to
Port. VirtualComponent may also have a reference to a Component object. In
this case Component has a derived, transient, volatile, read-only
reference named virtualPorts to all the Port objects of the referencing
VirtualComponent object.

The generated diagram editor only displays Component objects. Its Port
objects are displayed as attached subnodes. What I want is to also display
all its virtualPort objects - the Port objects contained by the
referencing VirtualComponent object - the same way:

http://www.rolleyes.de/pub/GMF_Editor.png

I added the following mapping to my mapping definition:

<children>
<containmentFeature

href=" ../metamodel/superstructure.ecore#//Diagram/AbstractComponen t/ports "/>
<childrenFeature

href=" ../metamodel/superstructure.ecore#//Diagram/Component/virtua lPorts "/>
<ownedChild>
<domainMetaElement
href="../metamodel/superstructure.ecore#//Diagram/Port"/>
<diagramNode
href="superstructure.gmfgraph#VirtualPort"/>
</ownedChild>
</children>

In a external model editor everything works well. But the GMF generated
editor refuses to display the virtual ports. I think the problem is
related to the fact, that the model element containing the ports is not
the model element associated with the EditPart displaying the ports.

Has anyone a hint or an alternative better solution?

Thanks in advance!

Report message to a moderator

Re: Derived feature as containment feature [message #230430 is a reply to message #230302]

Fri, 15 May 2009 09:44

Alexander Shatalin

Messages: 2928
Registered: July 2009

Senior Member

Hello Antonio,

Try using derived feature href=" ../metamodel/superstructure.ecore#//Diagram/Component/virtua lPorts "
as a containment feature for virtual ports. gmfmap editor will probably prevent
you from doing this, but you can modify xmi file as a text. As a result generated
diagram should be able to display "derived" ports just like a normal ports.
There can be some probles with creation od new derived ports - you have to
handle this in code implementing "virtualPorts" derived feature.

-----------------
Alex Shatalin

Report message to a moderator

Re: Derived feature as containment feature [message #230478 is a reply to message #230430]

Fri, 15 May 2009 13:44

Antonio Navarro Perez

Messages: 5
Registered: July 2009

Junior Member

Hi Alex,

Alex Shatalin wrote:

> Try using derived feature
href=" ../metamodel/superstructure.ecore#//Diagram/Component/virtua lPorts "
> as a containment feature for virtual ports. gmfmap editor will probably
prevent
> you from doing this, but you can modify xmi file as a text. As a result
generated
> diagram should be able to display "derived" ports just like a normal ports.

I've already tried that, but unfortunately it didn't work. My
implementation of the derived feature returns an
EcoreEList.UnmodifiableEList<Port>. (I also tried mutable collections as
return type, but that didn't work either.) I also modified the model code
to fire notifications when other features, on which the computation of the
derived feature depends, change. In pure EMF editors everything works
well. So it seems to be an GMF issue, but since I'm new to GMF I don't
know where to look for the problem.

Report message to a moderator

Re: Derived feature as containment feature [message #230491 is a reply to message #230478]

Fri, 15 May 2009 14:54

Antonio Navarro Perez

Messages: 5
Registered: July 2009

Junior Member

I've found a solution. The Problem was in
XXXVisualIDRegistry.getNodeVisualID(View containerView, EObject
domainElement). That method was not able to distinguish between ports and
virtual ports, because they share the same eClass. Therefore it always
returned the same visualID for both kinds of ports. I've added an
additional check for the superclass (Component or VirtualComponent). It's
smells like a hack, but it works.

Report message to a moderator

Previous Topic:	Dedicated behavior at link creation
Next Topic:	Visibility of view

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Thu Apr 25 17:34:53 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter