Home » Archived » GEF3D » intermodel connections and gmf(intermodel connections and gmf)
| |
Re: intermodel connections and gmf [message #493159 is a reply to message #492985] |
Fri, 23 October 2009 12:38 |
|
Dear Matthias,
there are two solutions for inter-model connections:
- UnidirectConnectionEditPart
- ConnectedElementAdapter pattern (which consists of several classes,
i.e. an EditPart, a model element and a figure.
The general problem both solutions address is that a model element and
its edit part are not aware of a connection. In GEF, both ends of a
connection need to know about this connection, that is both edit parts
need to know about it (not the model). In case of inter-model
connections, this usually isn't the case, as these special type of
connection cannot be visualized in a 2D editor.
The first solution, UnidirectConnectionEditPart, is the quicker and
easier solution, but it requires the (target) edit part of the
inter-model connection to support the creation of connection anchors
for all kind of connections. Unfortunately, this is not the case for
ShapeNodeEditPart, as it requires an
org.eclipse.gmf.runtime.diagram.ui.editparts.ConnectionEditP art, and
UnidirectConnectionEditPart is no such GMF specific edit part. IMHO
this is an GMF bug/problem, maybe we should file a bug report (a bugfix
is really easy) -- other GMF edit parts can in fact create anchors for
non-GMF edit parts.
So you have to use ConnectedElementAdapter instead, which is a little
bit more work to use, but it works with all kind of (target) edit
parts, as the target (and/or source) end is completely capsulated from
the connected element adapter. How does it work? Instead of the real
(taget) edit part (and model/figure), a dummy element, that is the
connected element adapter, is used as the target. The connected element
adapter listens to the figure of the real target and updates the
position accordingly. So, what you have to do is as follows:
- at some (container) edit part, usually the inter-model container edit
part, you have to create new ConnectedElementAdapters, set their
attributes accordingly (using the ReverseLookupManager) and return them
in getModelElements(). You will have to create such adapter model for
each connection end which isn't aware of the inter-model connection
(and which isn't handled otherwise, e.g. by a
UnidirectConnectionEditPart).
- in the EditPartFactory, create ConnectedElementEditParts for
ConnectedElementAdapters. The default implementation creates small
cubes as figures, you can subclass the editpart in order to create
invisible or other figures.
Hmm... I think that's it. In the package description of
org.eclipse.gef3d.ext.intermodel I have explained the pattern from a
structural point of view, I will add more explanation if necessary
(maybe you can give me a hint what information is missing or is
unclear).
Cheers,
Jens
P.S.: I filed an GMF bug report: https://bugs.eclipse.org/293160
On 2009-10-22 17:10:25 +0200, Matthias Then
<matthias.then@fernuni-hagen.de> said:
> in your article in the Eclipse-Magazine your working with intermodel
> connections. I tried to integrate these intermodel connections into my
> project the same way as you did in your demo project
> (de.eclipsemag.gef3d.sample). It doesn't work, the problem is the
> following operation:
> org.eclipse.gmf.runtime.diagram.ui.editparts.ShapeNodeEditPa rt.
> getTargetConnectionAnchor (org.eclipse.gef.ConnectionEditPart connEditPart)
>
> The operation starts with the following line:
> final org.eclipse.gmf.runtime.diagram.ui.editparts.ConnectionEditP art
> connection =
> (org.eclipse.gmf.runtime.diagram.ui.editparts.ConnectionEdit Part)
> connEditPart;
>
> In my case the ShapeNodeEditPart is a
> org.eclipse.uml2.diagram.clazz.edit.parts.Class2EditPart and the
> Connection is a MarkedElementEditPart. The class cast doesn't work.
> (The operation works for example for Class2EditParts and Associations.)
>
> Is anyone here, who already solved the problem to use intermodel
> connections with org.eclipse.uml2 - elements?
>
> Best regards,
> Matthias
|
|
| | |
Re: intermodel connections and gmf [message #563175 is a reply to message #492985] |
Fri, 23 October 2009 12:38 |
|
Dear Matthias,
there are two solutions for inter-model connections:
- UnidirectConnectionEditPart
- ConnectedElementAdapter pattern (which consists of several classes,
i.e. an EditPart, a model element and a figure.
The general problem both solutions address is that a model element and
its edit part are not aware of a connection. In GEF, both ends of a
connection need to know about this connection, that is both edit parts
need to know about it (not the model). In case of inter-model
connections, this usually isn't the case, as these special type of
connection cannot be visualized in a 2D editor.
The first solution, UnidirectConnectionEditPart, is the quicker and
easier solution, but it requires the (target) edit part of the
inter-model connection to support the creation of connection anchors
for all kind of connections. Unfortunately, this is not the case for
ShapeNodeEditPart, as it requires an
org.eclipse.gmf.runtime.diagram.ui.editparts.ConnectionEditP art, and
UnidirectConnectionEditPart is no such GMF specific edit part. IMHO
this is an GMF bug/problem, maybe we should file a bug report (a bugfix
is really easy) -- other GMF edit parts can in fact create anchors for
non-GMF edit parts.
So you have to use ConnectedElementAdapter instead, which is a little
bit more work to use, but it works with all kind of (target) edit
parts, as the target (and/or source) end is completely capsulated from
the connected element adapter. How does it work? Instead of the real
(taget) edit part (and model/figure), a dummy element, that is the
connected element adapter, is used as the target. The connected element
adapter listens to the figure of the real target and updates the
position accordingly. So, what you have to do is as follows:
- at some (container) edit part, usually the inter-model container edit
part, you have to create new ConnectedElementAdapters, set their
attributes accordingly (using the ReverseLookupManager) and return them
in getModelElements(). You will have to create such adapter model for
each connection end which isn't aware of the inter-model connection
(and which isn't handled otherwise, e.g. by a
UnidirectConnectionEditPart).
- in the EditPartFactory, create ConnectedElementEditParts for
ConnectedElementAdapters. The default implementation creates small
cubes as figures, you can subclass the editpart in order to create
invisible or other figures.
Hmm... I think that's it. In the package description of
org.eclipse.gef3d.ext.intermodel I have explained the pattern from a
structural point of view, I will add more explanation if necessary
(maybe you can give me a hint what information is missing or is
unclear).
Cheers,
Jens
P.S.: I filed an GMF bug report: https://bugs.eclipse.org/293160
On 2009-10-22 17:10:25 +0200, Matthias Then
<matthias.then@fernuni-hagen.de> said:
> in your article in the Eclipse-Magazine your working with intermodel
> connections. I tried to integrate these intermodel connections into my
> project the same way as you did in your demo project
> (de.eclipsemag.gef3d.sample). It doesn't work, the problem is the
> following operation:
> org.eclipse.gmf.runtime.diagram.ui.editparts.ShapeNodeEditPa rt.
> getTargetConnectionAnchor (org.eclipse.gef.ConnectionEditPart connEditPart)
>
> The operation starts with the following line:
> final org.eclipse.gmf.runtime.diagram.ui.editparts.ConnectionEditP art
> connection =
> (org.eclipse.gmf.runtime.diagram.ui.editparts.ConnectionEdit Part)
> connEditPart;
>
> In my case the ShapeNodeEditPart is a
> org.eclipse.uml2.diagram.clazz.edit.parts.Class2EditPart and the
> Connection is a MarkedElementEditPart. The class cast doesn't work.
> (The operation works for example for Class2EditParts and Associations.)
>
> Is anyone here, who already solved the problem to use intermodel
> connections with org.eclipse.uml2 - elements?
>
> Best regards,
> Matthias
|
|
| |
Goto Forum:
Current Time: Wed Sep 25 22:08:40 GMT 2024
Powered by FUDForum. Page generated in 0.07521 seconds
|