Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » GEF » Connections as Nodes
Connections as Nodes [message #205959] Fri, 23 December 2005 11:50 Go to next message
Roger Villars is currently offline Roger VillarsFriend
Messages: 57
Registered: July 2009
Member
Hi!



I would like to build an editor for an existing EMF model. This model
consists of only one type of elements (nodes) and one type of link to
connect them.



In GEF normally the nodes "know" how they are connected (with
getModelSourceConnections() and getModelTargetConnection()).



But in my case a connection is also a child of the model and it should hold
the connection information (with something like getConnectionSource() and
getConnectionTarget()).

The Nodes don't have to know about this.



Is it possible to implement this approach with GEF and if yes, how?



Thanks and best regards,

Roger
Re: Connections as Nodes [message #205967 is a reply to message #205959] Fri, 23 December 2005 12:13 Go to previous messageGo to next message
Didier Villevalois is currently offline Didier VillevaloisFriend
Messages: 86
Registered: July 2009
Member
Hi Roger,

I think you could use one of EMF's EcoreUtil.CrossReferencer subclasses,
to implement two derived-transient-volative features (namely
sourceConnections and targetConnections) to your nodes.

Didier.

Roger Villars wrote:
> Hi!
>
>
>
> I would like to build an editor for an existing EMF model. This model
> consists of only one type of elements (nodes) and one type of link to
> connect them.
>
>
>
> In GEF normally the nodes "know" how they are connected (with
> getModelSourceConnections() and getModelTargetConnection()).
>
>
>
> But in my case a connection is also a child of the model and it should hold
> the connection information (with something like getConnectionSource() and
> getConnectionTarget()).
>
> The Nodes don't have to know about this.
>
>
>
> Is it possible to implement this approach with GEF and if yes, how?
>
>
>
> Thanks and best regards,
>
> Roger
>
>
>
Re: Connections as Nodes [message #205973 is a reply to message #205967] Fri, 23 December 2005 13:31 Go to previous messageGo to next message
Roger Villars is currently offline Roger VillarsFriend
Messages: 57
Registered: July 2009
Member
I agree, but my problem is the notification of the model if I create/delete
connections. Normally this is done on the nodes. If the node property that
holds the sourceConnections/targetConnections is changed, then notifyChanged
is called on the node part by the notification adapter. This calls
refreshTargetConnections() and refreshSourceConnection(). This then redraws
the connections.



In my case only the connection is informed if its source or target
properties change. And calling refreshTargetConnections() on a connection
doesn't seem to work.



"Ptitjes" <ptitjes@beuz.org> schrieb im Newsbeitrag
news:dogpkv$mdq$1@utils.eclipse.org...
> Hi Roger,
>
> I think you could use one of EMF's EcoreUtil.CrossReferencer subclasses,
> to implement two derived-transient-volative features (namely
> sourceConnections and targetConnections) to your nodes.
>
> Didier.
>
> Roger Villars wrote:
>> Hi!
>>
>>
>>
>> I would like to build an editor for an existing EMF model. This model
>> consists of only one type of elements (nodes) and one type of link to
>> connect them.
>>
>>
>>
>> In GEF normally the nodes "know" how they are connected (with
>> getModelSourceConnections() and getModelTargetConnection()).
>>
>>
>>
>> But in my case a connection is also a child of the model and it should
>> hold the connection information (with something like
>> getConnectionSource() and getConnectionTarget()).
>>
>> The Nodes don't have to know about this.
>>
>>
>>
>> Is it possible to implement this approach with GEF and if yes, how?
>>
>>
>>
>> Thanks and best regards,
>>
>> Roger
>>
>>
Re: Connections as Nodes [message #205980 is a reply to message #205973] Fri, 23 December 2005 14:30 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: daniel.rohe.stud.tu-ilmenau.de

You can make a refreshChildren() on the model if you can navigate from
the connection back to the model.

Kind regards,
Daniel

Roger Villars schrieb:
> I agree, but my problem is the notification of the model if I create/delete
> connections. Normally this is done on the nodes. If the node property that
> holds the sourceConnections/targetConnections is changed, then notifyChanged
> is called on the node part by the notification adapter. This calls
> refreshTargetConnections() and refreshSourceConnection(). This then redraws
> the connections.
>
>
>
> In my case only the connection is informed if its source or target
> properties change. And calling refreshTargetConnections() on a connection
> doesn't seem to work.
>
>
>
> "Ptitjes" <ptitjes@beuz.org> schrieb im Newsbeitrag
> news:dogpkv$mdq$1@utils.eclipse.org...
>
>>Hi Roger,
>>
>>I think you could use one of EMF's EcoreUtil.CrossReferencer subclasses,
>>to implement two derived-transient-volative features (namely
>>sourceConnections and targetConnections) to your nodes.
>>
>>Didier.
>>
>>Roger Villars wrote:
>>
>>>Hi!
>>>
>>>
>>>
>>>I would like to build an editor for an existing EMF model. This model
>>>consists of only one type of elements (nodes) and one type of link to
>>>connect them.
>>>
>>>
>>>
>>>In GEF normally the nodes "know" how they are connected (with
>>>getModelSourceConnections() and getModelTargetConnection()).
>>>
>>>
>>>
>>>But in my case a connection is also a child of the model and it should
>>>hold the connection information (with something like
>>>getConnectionSource() and getConnectionTarget()).
>>>
>>>The Nodes don't have to know about this.
>>>
>>>
>>>
>>>Is it possible to implement this approach with GEF and if yes, how?
>>>
>>>
>>>
>>>Thanks and best regards,
>>>
>>>Roger
>>>
>>>
>
>
Re: Connections as Nodes [message #205996 is a reply to message #205980] Fri, 23 December 2005 16:48 Go to previous messageGo to next message
Roger Villars is currently offline Roger VillarsFriend
Messages: 57
Registered: July 2009
Member
Thanks for all your anwers!

> You can make a refreshChildren() on the model if you can navigate from the
> connection back to the model.

In Fact I'm already doing this, but as its name says, refreshChildren() only
refreshes the children
on the EditPart on which it is called.

Things are a bit more complicated.
My Model is based on an XML Schema. It creates code that looks like this:

<chart>
<units>
<unit id="unit1"></Unit>
<unit id="unit2"></Unit>
</units>
<connections>
<connection source="unit1" target="unit2"></connection>
</connections>
<charts>

The 'chart' editpart is my canvas for GEF and so the container for the
'unit' and 'connection' editparts.
But as you can see, because of the xml schema, the model created by EMF has
an additional layer <units> and <connections>.
So for the model, 'unit' and 'connection' are not childen of 'chart' but of
'connections' and 'units'.

For 'unit' I solved this by overriding the getModelChildren() method on the
'chart'editpart. It does something like:
return getChart().getUnits().getUnit();
With this, for GEF 'unit' is a child of 'chart'.

I also added the 'chart' editpart as listener for the 'units' model with:
((Notifier)getChart().getUnits()).eAdapters().add(this);
in the activate() method of the 'chart' editpart.
With this, the 'chart' editpart is notified if I add a 'unit' to 'units'.

For the 'connection', this does not seem to work. As above, for GEF the
'connection' has to be
child of 'chart' to be refreshd by refreshChildren().

I enhanced my getModelChildren() method like this:

List modelChildren = new ArrayList();
modelChildren.addAll(getChart().getUnits().getUnit());
modelChildren.addAll(getChart().getConnections().getConnecti on());
return modelChildren;

Unfortunately, after that I got this exception while loading my file:

java.lang.IndexOutOfBoundsException: Index does not exist
at org.eclipse.draw2d.Figure.add(Figure.java:137)
at org.eclipse.draw2d.FreeformLayer.add(FreeformLayer.java:31)
at org.eclipse.draw2d.Figure.add(Figure.java:179)
at
org.eclipse.gef.editparts.AbstractGraphicalEditPart.addChild Visual(AbstractGraphicalEditPart.java:198)
at
org.eclipse.gef.editparts.AbstractEditPart.addChild(Abstract EditPart.java:194)
at
org.eclipse.gef.editparts.AbstractEditPart.refreshChildren(A bstractEditPart.java:734)
at
org.eclipse.gef.editparts.AbstractEditPart.refresh(AbstractE ditPart.java:684)
at
org.eclipse.gef.editparts.AbstractGraphicalEditPart.refresh( AbstractGraphicalEditPart.java:554)
at
org.eclipse.gef.editparts.AbstractEditPart.addNotify(Abstrac tEditPart.java:232)
at
org.eclipse.gef.editparts.AbstractGraphicalEditPart.addNotif y(AbstractGraphicalEditPart.java:212)
at
org.eclipse.gef.editparts.AbstractEditPart.addChild(Abstract EditPart.java:195)
at
org.eclipse.gef.editparts.FreeformGraphicalRootEditPart.setC ontents(FreeformGraphicalRootEditPart.java:303)
at
org.eclipse.gef.ui.parts.AbstractEditPartViewer.setContents( AbstractEditPartViewer.java:583)
at
org.eclipse.gef.ui.parts.AbstractEditPartViewer.setContents( AbstractEditPartViewer.java:592)
at
ch.mimacom.edoras.edscc.editor.EdsccEditorPage.createGraphic alViewer(EdsccEditorPage.java:101)
etc.

I studied examples (shapesemf, etc.) and connections are never children of
the canvas. They aren't refreshed by
refreshChildren() but by the nodes with refreshTargetConnections(). But that
is what I can't do :-)






"Daniel Rohe" <daniel.rohe@stud.tu-ilmenau.de> schrieb im Newsbeitrag
news:doh1ml$uva$1@utils.eclipse.org...
> You can make a refreshChildren() on the model if you can navigate from the
> connection back to the model.
>
> Kind regards,
> Daniel
>
> Roger Villars schrieb:
>> I agree, but my problem is the notification of the model if I
>> create/delete connections. Normally this is done on the nodes. If the
>> node property that holds the sourceConnections/targetConnections is
>> changed, then notifyChanged is called on the node part by the
>> notification adapter. This calls refreshTargetConnections() and
>> refreshSourceConnection(). This then redraws the connections.
>>
>>
>>
>> In my case only the connection is informed if its source or target
>> properties change. And calling refreshTargetConnections() on a connection
>> doesn't seem to work.
>>
>>
>>
>> "Ptitjes" <ptitjes@beuz.org> schrieb im Newsbeitrag
>> news:dogpkv$mdq$1@utils.eclipse.org...
>>
>>>Hi Roger,
>>>
>>>I think you could use one of EMF's EcoreUtil.CrossReferencer subclasses,
>>>to implement two derived-transient-volative features (namely
>>>sourceConnections and targetConnections) to your nodes.
>>>
>>>Didier.
>>>
>>>Roger Villars wrote:
>>>
>>>>Hi!
>>>>
>>>>
>>>>
>>>>I would like to build an editor for an existing EMF model. This model
>>>>consists of only one type of elements (nodes) and one type of link to
>>>>connect them.
>>>>
>>>>
>>>>
>>>>In GEF normally the nodes "know" how they are connected (with
>>>>getModelSourceConnections() and getModelTargetConnection()).
>>>>
>>>>
>>>>
>>>>But in my case a connection is also a child of the model and it should
>>>>hold the connection information (with something like
>>>>getConnectionSource() and getConnectionTarget()).
>>>>
>>>>The Nodes don't have to know about this.
>>>>
>>>>
>>>>
>>>>Is it possible to implement this approach with GEF and if yes, how?
>>>>
>>>>
>>>>
>>>>Thanks and best regards,
>>>>
>>>>Roger
>>>>
>>>>
>>
Re: Connections as Nodes [message #206012 is a reply to message #205996] Fri, 23 December 2005 18:06 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: daniel.rohe.stud.tu-ilmenau.de

If you can navigate from Unit to Chart you could override the
getModelSourceConnections() and getModelTargetConnections() of
UnitEditPart to navigate to Chart and then to the Connection list and
search for the Connections that have the current Unit as source or
target and return them for this Unit. The found Connection objects
should be stored in the UnitEditPart. Also should the UnitEditPart be
added as notification adapter to the Connections object to get notified
if a Connection object is added or removed and to the Connection to get
notified if source or target has changed. The ConnectionEditPart should
also react on source or target changes and retrieve the UnitEditPart
from the viewer to refresh its source and target connections. Therefor
the refreshSourceConnections and refreshTargetConnections method should
be made public.

Kind regards,
Daniel

Roger Villars schrieb:
> Thanks for all your anwers!
>
>
>>You can make a refreshChildren() on the model if you can navigate from the
>>connection back to the model.
>
>
> In Fact I'm already doing this, but as its name says, refreshChildren() only
> refreshes the children
> on the EditPart on which it is called.
>
> Things are a bit more complicated.
> My Model is based on an XML Schema. It creates code that looks like this:
>
> <chart>
> <units>
> <unit id="unit1"></Unit>
> <unit id="unit2"></Unit>
> </units>
> <connections>
> <connection source="unit1" target="unit2"></connection>
> </connections>
> <charts>
>
> The 'chart' editpart is my canvas for GEF and so the container for the
> 'unit' and 'connection' editparts.
> But as you can see, because of the xml schema, the model created by EMF has
> an additional layer <units> and <connections>.
> So for the model, 'unit' and 'connection' are not childen of 'chart' but of
> 'connections' and 'units'.
>
> For 'unit' I solved this by overriding the getModelChildren() method on the
> 'chart'editpart. It does something like:
> return getChart().getUnits().getUnit();
> With this, for GEF 'unit' is a child of 'chart'.
>
> I also added the 'chart' editpart as listener for the 'units' model with:
> ((Notifier)getChart().getUnits()).eAdapters().add(this);
> in the activate() method of the 'chart' editpart.
> With this, the 'chart' editpart is notified if I add a 'unit' to 'units'.
>
> For the 'connection', this does not seem to work. As above, for GEF the
> 'connection' has to be
> child of 'chart' to be refreshd by refreshChildren().
>
> I enhanced my getModelChildren() method like this:
>
> List modelChildren = new ArrayList();
> modelChildren.addAll(getChart().getUnits().getUnit());
> modelChildren.addAll(getChart().getConnections().getConnecti on());
> return modelChildren;
>
> Unfortunately, after that I got this exception while loading my file:
>
> java.lang.IndexOutOfBoundsException: Index does not exist
> at org.eclipse.draw2d.Figure.add(Figure.java:137)
> at org.eclipse.draw2d.FreeformLayer.add(FreeformLayer.java:31)
> at org.eclipse.draw2d.Figure.add(Figure.java:179)
> at
> org.eclipse.gef.editparts.AbstractGraphicalEditPart.addChild Visual(AbstractGraphicalEditPart.java:198)
> at
> org.eclipse.gef.editparts.AbstractEditPart.addChild(Abstract EditPart.java:194)
> at
> org.eclipse.gef.editparts.AbstractEditPart.refreshChildren(A bstractEditPart.java:734)
> at
> org.eclipse.gef.editparts.AbstractEditPart.refresh(AbstractE ditPart.java:684)
> at
> org.eclipse.gef.editparts.AbstractGraphicalEditPart.refresh( AbstractGraphicalEditPart.java:554)
> at
> org.eclipse.gef.editparts.AbstractEditPart.addNotify(Abstrac tEditPart.java:232)
> at
> org.eclipse.gef.editparts.AbstractGraphicalEditPart.addNotif y(AbstractGraphicalEditPart.java:212)
> at
> org.eclipse.gef.editparts.AbstractEditPart.addChild(Abstract EditPart.java:195)
> at
> org.eclipse.gef.editparts.FreeformGraphicalRootEditPart.setC ontents(FreeformGraphicalRootEditPart.java:303)
> at
> org.eclipse.gef.ui.parts.AbstractEditPartViewer.setContents( AbstractEditPartViewer.java:583)
> at
> org.eclipse.gef.ui.parts.AbstractEditPartViewer.setContents( AbstractEditPartViewer.java:592)
> at
> ch.mimacom.edoras.edscc.editor.EdsccEditorPage.createGraphic alViewer(EdsccEditorPage.java:101)
> etc.
>
> I studied examples (shapesemf, etc.) and connections are never children of
> the canvas. They aren't refreshed by
> refreshChildren() but by the nodes with refreshTargetConnections(). But that
> is what I can't do :-)
>
>
>
>
>
>
> "Daniel Rohe" <daniel.rohe@stud.tu-ilmenau.de> schrieb im Newsbeitrag
> news:doh1ml$uva$1@utils.eclipse.org...
>
>>You can make a refreshChildren() on the model if you can navigate from the
>>connection back to the model.
>>
>>Kind regards,
>>Daniel
>>
>>Roger Villars schrieb:
>>
>>>I agree, but my problem is the notification of the model if I
>>>create/delete connections. Normally this is done on the nodes. If the
>>>node property that holds the sourceConnections/targetConnections is
>>>changed, then notifyChanged is called on the node part by the
>>>notification adapter. This calls refreshTargetConnections() and
>>>refreshSourceConnection(). This then redraws the connections.
>>>
>>>
>>>
>>>In my case only the connection is informed if its source or target
>>>properties change. And calling refreshTargetConnections() on a connection
>>>doesn't seem to work.
>>>
>>>
>>>
>>>"Ptitjes" <ptitjes@beuz.org> schrieb im Newsbeitrag
>>>news:dogpkv$mdq$1@utils.eclipse.org...
>>>
>>>
>>>>Hi Roger,
>>>>
>>>>I think you could use one of EMF's EcoreUtil.CrossReferencer subclasses,
>>>>to implement two derived-transient-volative features (namely
>>>>sourceConnections and targetConnections) to your nodes.
>>>>
>>>>Didier.
>>>>
>>>>Roger Villars wrote:
>>>>
>>>>
>>>>>Hi!
>>>>>
>>>>>
>>>>>
>>>>>I would like to build an editor for an existing EMF model. This model
>>>>>consists of only one type of elements (nodes) and one type of link to
>>>>>connect them.
>>>>>
>>>>>
>>>>>
>>>>>In GEF normally the nodes "know" how they are connected (with
>>>>>getModelSourceConnections() and getModelTargetConnection()).
>>>>>
>>>>>
>>>>>
>>>>>But in my case a connection is also a child of the model and it should
>>>>>hold the connection information (with something like
>>>>>getConnectionSource() and getConnectionTarget()).
>>>>>
>>>>>The Nodes don't have to know about this.
>>>>>
>>>>>
>>>>>
>>>>>Is it possible to implement this approach with GEF and if yes, how?
>>>>>
>>>>>
>>>>>
>>>>>Thanks and best regards,
>>>>>
>>>>>Roger
>>>>>
>>>>>
>>>
>
>
Re: Connections as Nodes [message #206536 is a reply to message #206012] Tue, 03 January 2006 09:18 Go to previous message
Roger Villars is currently offline Roger VillarsFriend
Messages: 57
Registered: July 2009
Member
Sorry for the delay. Chrismas and all this stuff...

> If you can navigate from Unit to Chart you could override the
> getModelSourceConnections() and getModelTargetConnections() of
> UnitEditPart to navigate to Chart and then to the Connection list and
> search for the Connections that have the current Unit as source or target
> and return them for this Unit. The found Connection objects should be
> stored in the UnitEditPart.

Done.

>Also should the UnitEditPart be added as notification adapter to the
>Connections object to get notified if a Connection object is added or
>removed

Done.

>and to the Connection to get notified if source or target has changed.

Did not do that. That was the problem.

>The ConnectionEditPart should also react on source or target changes and
>retrieve the UnitEditPart from the viewer to refresh its source and target
>connections. Therefor the refreshSourceConnections and
>refreshTargetConnections method should be made public.

It works now and I'm happy. Thanks to all helpers, especially to Daniel.

Roger


"Daniel Rohe" <daniel.rohe@stud.tu-ilmenau.de> schrieb im Newsbeitrag
news:doheao$3hs$1@utils.eclipse.org...
> If you can navigate from Unit to Chart you could override the
> getModelSourceConnections() and getModelTargetConnections() of
> UnitEditPart to navigate to Chart and then to the Connection list and
> search for the Connections that have the current Unit as source or target
> and return them for this Unit. The found Connection objects should be
> stored in the UnitEditPart. Also should the UnitEditPart be added as
> notification adapter to the Connections object to get notified if a
> Connection object is added or removed and to the Connection to get
> notified if source or target has changed. The ConnectionEditPart should
> also react on source or target changes and retrieve the UnitEditPart from
> the viewer to refresh its source and target connections. Therefor the
> refreshSourceConnections and refreshTargetConnections method should be
> made public.
>
> Kind regards,
> Daniel
>
> Roger Villars schrieb:
>> Thanks for all your anwers!
>>
>>
>>>You can make a refreshChildren() on the model if you can navigate from
>>>the
>>>connection back to the model.
>>
>>
>> In Fact I'm already doing this, but as its name says, refreshChildren()
>> only
>> refreshes the children
>> on the EditPart on which it is called.
>>
>> Things are a bit more complicated.
>> My Model is based on an XML Schema. It creates code that looks like this:
>>
>> <chart>
>> <units>
>> <unit id="unit1"></Unit>
>> <unit id="unit2"></Unit>
>> </units>
>> <connections>
>> <connection source="unit1" target="unit2"></connection>
>> </connections>
>> <charts>
>>
>> The 'chart' editpart is my canvas for GEF and so the container for the
>> 'unit' and 'connection' editparts.
>> But as you can see, because of the xml schema, the model created by EMF
>> has
>> an additional layer <units> and <connections>.
>> So for the model, 'unit' and 'connection' are not childen of 'chart' but
>> of
>> 'connections' and 'units'.
>>
>> For 'unit' I solved this by overriding the getModelChildren() method on
>> the
>> 'chart'editpart. It does something like:
>> return getChart().getUnits().getUnit();
>> With this, for GEF 'unit' is a child of 'chart'.
>>
>> I also added the 'chart' editpart as listener for the 'units' model with:
>> ((Notifier)getChart().getUnits()).eAdapters().add(this);
>> in the activate() method of the 'chart' editpart.
>> With this, the 'chart' editpart is notified if I add a 'unit' to 'units'.
>>
>> For the 'connection', this does not seem to work. As above, for GEF the
>> 'connection' has to be
>> child of 'chart' to be refreshd by refreshChildren().
>>
>> I enhanced my getModelChildren() method like this:
>>
>> List modelChildren = new ArrayList();
>> modelChildren.addAll(getChart().getUnits().getUnit());
>> modelChildren.addAll(getChart().getConnections().getConnecti on());
>> return modelChildren;
>>
>> Unfortunately, after that I got this exception while loading my file:
>>
>> java.lang.IndexOutOfBoundsException: Index does not exist
>> at org.eclipse.draw2d.Figure.add(Figure.java:137)
>> at org.eclipse.draw2d.FreeformLayer.add(FreeformLayer.java:31)
>> at org.eclipse.draw2d.Figure.add(Figure.java:179)
>> at
>> org.eclipse.gef.editparts.AbstractGraphicalEditPart.addChild Visual(AbstractGraphicalEditPart.java:198)
>> at
>> org.eclipse.gef.editparts.AbstractEditPart.addChild(Abstract EditPart.java:194)
>> at
>> org.eclipse.gef.editparts.AbstractEditPart.refreshChildren(A bstractEditPart.java:734)
>> at
>> org.eclipse.gef.editparts.AbstractEditPart.refresh(AbstractE ditPart.java:684)
>> at
>> org.eclipse.gef.editparts.AbstractGraphicalEditPart.refresh( AbstractGraphicalEditPart.java:554)
>> at
>> org.eclipse.gef.editparts.AbstractEditPart.addNotify(Abstrac tEditPart.java:232)
>> at
>> org.eclipse.gef.editparts.AbstractGraphicalEditPart.addNotif y(AbstractGraphicalEditPart.java:212)
>> at
>> org.eclipse.gef.editparts.AbstractEditPart.addChild(Abstract EditPart.java:195)
>> at
>> org.eclipse.gef.editparts.FreeformGraphicalRootEditPart.setC ontents(FreeformGraphicalRootEditPart.java:303)
>> at
>> org.eclipse.gef.ui.parts.AbstractEditPartViewer.setContents( AbstractEditPartViewer.java:583)
>> at
>> org.eclipse.gef.ui.parts.AbstractEditPartViewer.setContents( AbstractEditPartViewer.java:592)
>> at
>> ch.mimacom.edoras.edscc.editor.EdsccEditorPage.createGraphic alViewer(EdsccEditorPage.java:101)
>> etc.
>>
>> I studied examples (shapesemf, etc.) and connections are never children
>> of
>> the canvas. They aren't refreshed by
>> refreshChildren() but by the nodes with refreshTargetConnections(). But
>> that
>> is what I can't do :-)
>>
>>
>>
>>
>>
>>
>> "Daniel Rohe" <daniel.rohe@stud.tu-ilmenau.de> schrieb im Newsbeitrag
>> news:doh1ml$uva$1@utils.eclipse.org...
>>
>>>You can make a refreshChildren() on the model if you can navigate from
>>>the
>>>connection back to the model.
>>>
>>>Kind regards,
>>>Daniel
>>>
>>>Roger Villars schrieb:
>>>
>>>>I agree, but my problem is the notification of the model if I
>>>>create/delete connections. Normally this is done on the nodes. If the
>>>>node property that holds the sourceConnections/targetConnections is
>>>>changed, then notifyChanged is called on the node part by the
>>>>notification adapter. This calls refreshTargetConnections() and
>>>>refreshSourceConnection(). This then redraws the connections.
>>>>
>>>>
>>>>
>>>>In my case only the connection is informed if its source or target
>>>>properties change. And calling refreshTargetConnections() on a
>>>>connection
>>>>doesn't seem to work.
>>>>
>>>>
>>>>
>>>>"Ptitjes" <ptitjes@beuz.org> schrieb im Newsbeitrag
>>>>news:dogpkv$mdq$1@utils.eclipse.org...
>>>>
>>>>
>>>>>Hi Roger,
>>>>>
>>>>>I think you could use one of EMF's EcoreUtil.CrossReferencer
>>>>>subclasses,
>>>>>to implement two derived-transient-volative features (namely
>>>>>sourceConnections and targetConnections) to your nodes.
>>>>>
>>>>>Didier.
>>>>>
>>>>>Roger Villars wrote:
>>>>>
>>>>>
>>>>>>Hi!
>>>>>>
>>>>>>
>>>>>>
>>>>>>I would like to build an editor for an existing EMF model. This model
>>>>>>consists of only one type of elements (nodes) and one type of link to
>>>>>>connect them.
>>>>>>
>>>>>>
>>>>>>
>>>>>>In GEF normally the nodes "know" how they are connected (with
>>>>>>getModelSourceConnections() and getModelTargetConnection()).
>>>>>>
>>>>>>
>>>>>>
>>>>>>But in my case a connection is also a child of the model and it should
>>>>>>hold the connection information (with something like
>>>>>>getConnectionSource() and getConnectionTarget()).
>>>>>>
>>>>>>The Nodes don't have to know about this.
>>>>>>
>>>>>>
>>>>>>
>>>>>>Is it possible to implement this approach with GEF and if yes, how?
>>>>>>
>>>>>>
>>>>>>
>>>>>>Thanks and best regards,
>>>>>>
>>>>>>Roger
>>>>>>
>>>>>>
>>>>
>>
Previous Topic:Simple line drawing EditPart
Next Topic:Automatic Graph Layout that Honors Edge Labels?
Goto Forum:
  


Current Time: Mon Sep 23 23:59:54 GMT 2024

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

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

Back to the top