Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » GEF » Non-binary connections - how do you model them?
Non-binary connections - how do you model them? [message #160079] Thu, 02 December 2004 04:53 Go to next message
Barry Lay is currently offline Barry LayFriend
Messages: 48
Registered: July 2009
Member
I have a requirement for a non-binary association between objects, and
am curious about how one might model it graphically. As an example, it
is not unreasonable to stipulate that "a is between b and c" or "d is
the minimum of e, f, and g".

The GEF connection mechanism doesn't lend itself to multiply-ended
connections so I am inclined to think that this would require an
association object to represent the relationship with several
point-to-point connections between it and its participants. It would be
nice, however, to have that relationship automatically (graphically)
ride the middle of the connections around like a label when the leaf
nodes are moved, as part of the connection router.

I recall that VisualAge had connections to connections to provide
parameters to associations; this isn't quite like that but does move in
that direction. I haven't tried doing this sort of thing in GEF. Is
this a reasonable thing to do? How do you specify the attachment point
for an inbound connection on a connection?

On a related note, if a proper EditPart would be needed to represent the
relationship it would be nice if its figure could be non-rectangular to
better match common practice in diagramming. Are there examples of this
about?

Thanks,
Barry
Re: Non-binary connections - how do you model them? [message #160087 is a reply to message #160079] Thu, 02 December 2004 10:56 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: usenet.jevopi.de

On 2004-12-02 05:53:48 +0100, Barry Lay <blay@laysercomputing.com> said:

> I have a requirement for a non-binary association between objects, and
> am curious about how one might model it graphically.

I think there are two possibilities:

1) Model the association as (invisible) node
The association is modeled just like the assiciation in UML 2. The
association is represented as a node, and every linked "real" node is
connected with a binary connection. Maybe it's possible to hide the
association node itsself, e.g. by creating a figure with dimension
(0,0) or (1,1). If you have to move the association node -- the user is
moving the center point of the n-ary association -- the bounds of the
node might be greater and you have to provide proper anchor points. The
advantage of this apporach is that you have to managy binay connections
only.

2) Model the association as Connection and Node
You can implement both interfaces, the Connection and the Node
interface. That's no problem. I've implemented a class diagram editor
and I needed this for conecting Comments to a Relationship, e.g.
connect a Comment to a Generalization with a CommentLink-Connection.
The result may look like the first approach and you can use bendpoints
for the same puprpose as the center node in the first approach.

Depending on where and how may labes and other decorations you have to
provide, maybe the first or the second approach are more suiteable for
you. Maybe I like the first case more since it's more straight forward.

Jens
Re: Non-binary connections - how do you model them? [message #160094 is a reply to message #160087] Thu, 02 December 2004 12:20 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: Lamont_Gilbert.rigidsoftware.com

I would create an invisible editpart that was capable of holding
multiple nodes. Then I would make sure there was always a node for any
new connections present.

I tried having a node accept more than 1 connection but I found it did
not match at all the GEF framework. There was however no problem with
having 1 editpart to house several nodes and give the appearance of
connecting multiple lines to one point.

This editpart can listen to the other editparts that house nodes, and
move when they move if needs be. Also move when any of its connectoins
get reconnected.



Jens v. P. wrote:
> On 2004-12-02 05:53:48 +0100, Barry Lay <blay@laysercomputing.com> said:
>
>> I have a requirement for a non-binary association between objects, and
>> am curious about how one might model it graphically.
>
>
> I think there are two possibilities:
>
> 1) Model the association as (invisible) node
> The association is modeled just like the assiciation in UML 2. The
> association is represented as a node, and every linked "real" node is
> connected with a binary connection. Maybe it's possible to hide the
> association node itsself, e.g. by creating a figure with dimension (0,0)
> or (1,1). If you have to move the association node -- the user is moving
> the center point of the n-ary association -- the bounds of the node
> might be greater and you have to provide proper anchor points. The
> advantage of this apporach is that you have to managy binay connections
> only.
>
> 2) Model the association as Connection and Node
> You can implement both interfaces, the Connection and the Node
> interface. That's no problem. I've implemented a class diagram editor
> and I needed this for conecting Comments to a Relationship, e.g. connect
> a Comment to a Generalization with a CommentLink-Connection. The result
> may look like the first approach and you can use bendpoints for the same
> puprpose as the center node in the first approach.
>
> Depending on where and how may labes and other decorations you have to
> provide, maybe the first or the second approach are more suiteable for
> you. Maybe I like the first case more since it's more straight forward.
>
> Jens
>
>


--
Respectfully,


CL Gilbert

"Verily, verily, I say unto you, He that entereth not by the door() into
the sheepfold{}, but climbeth up some other *way, the same is a thief
and a robber."

GnuPG Key Fingerprint:
82A6 8893 C2A1 F64E A9AD 19AE 55B2 4CD7 80D2 0A2D

For a free Java interface to Freechess.org see
http://www.rigidsoftware.com/Chess/chess.html
Re: Non-binary connections - how do you model them? [message #160264 is a reply to message #160094] Fri, 03 December 2004 06:05 Go to previous messageGo to next message
Barry Lay is currently offline Barry LayFriend
Messages: 48
Registered: July 2009
Member
Thanks very much for your comments.

I can see definite benefits in having a concrete EditPart that
represents the connection point for the relationship.

My problem now lies in how to move it around. It would appear that I
want a part that responds to its graphical neighbours rather than ask
its model element for its location. This leads me to a problem - the
model now can't help with that aspect, nor can other parts of the model
since they don't know enough details of the graphical nature of the
surrounds such as where the connection anchors are that should indicate
where the relationship part should place itself.

This leads to a problem I have with the design of GEF: the arbitrary
nature of the separation of model and graphics in reality doesn't seem
well designed. The model should not know about pixel locations and the
EditParts should be able to know about their counterparts without going
through the model. I am moving towards having layout managers place
everything with "hints" from the model so that the model will never have
reliable graphical locators. I would also like to have graphical
elements that don't correspond to model elements at all. The tutorial
mentions that this is possible but I don't see how to reference an
EditPart that isn't matched to a model element.

Barry

CL [dnoyeb] Gilbert wrote:
> I would create an invisible editpart that was capable of holding
> multiple nodes. Then I would make sure there was always a node for any
> new connections present.
>
....
> Jens v. P. wrote:
>
>> On 2004-12-02 05:53:48 +0100, Barry Lay <blay@laysercomputing.com> said:
>>
>>> I have a requirement for a non-binary association between objects,
>>> and am curious about how one might model it graphically.
>>
>>
>>
>> I think there are two possibilities:
>>
>> 1) Model the association as (invisible) node
>> 2) Model the association as Connection and Node
>> You can implement both interfaces, the Connection and the Node
>> interface. That's no problem. I've implemented a class diagram editor
>> and I needed this for conecting Comments to a Relationship, e.g.
>> connect a Comment to a Generalization with a CommentLink-Connection.
>> The result may look like the first approach and you can use bendpoints
>> for the same puprpose as the center node in the first approach.
Re: Non-binary connections - how do you model them? [message #160296 is a reply to message #160264] Fri, 03 December 2004 07:50 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: Lamont_Gilbert.rigidsoftware.com

Barry Lay wrote:
> Thanks very much for your comments.
>
> I can see definite benefits in having a concrete EditPart that
> represents the connection point for the relationship.
>
> My problem now lies in how to move it around. It would appear that I
> want a part that responds to its graphical neighbours rather than ask
> its model element for its location. This leads me to a problem - the
> model now can't help with that aspect, nor can other parts of the model
> since they don't know enough details of the graphical nature of the
> surrounds such as where the connection anchors are that should indicate
> where the relationship part should place itself.
>

You want a model that responds to its model neighbors. So the model of
this particular edit part can listen to the models of the editparts that
it will be positioning itself based upon. So this model wont be storing
its x,y position since that is calculated dynamically at runtime based
on the position of the models it listens too. But it will have to store
which models it is listening to.

> This leads to a problem I have with the design of GEF: the arbitrary
> nature of the separation of model and graphics in reality doesn't seem
> well designed. The model should not know about pixel locations and the
> EditParts should be able to know about their counterparts without going
> through the model. I am moving towards having layout managers place
> everything with "hints" from the model so that the model will never have
> reliable graphical locators. I would also like to have graphical
> elements that don't correspond to model elements at all. The tutorial
> mentions that this is possible but I don't see how to reference an
> EditPart that isn't matched to a model element.
>

I would say, anything that needs to be stored should be in the model.
Also, anything which will never vary no matter what edit part is showing
it should also be in the model. That is, you can have many edit parts
for the same model. For instance, I have 1 editpart I use when a model
is being edited by a particular editor, and a different editpart I use
when the model is being displayed by another editor. Since both
editparts count on the same location offset informatoin, I put the
method on the model that can calculate the offset, instead of having
each editpart do it by itself.

This also allows me to handle the models children differently depending
on where the model is being displayed. (sometimes the children are
selectable, sometimes not)

I would suggest you just get right into coding by biting off a small
chunk. Once you implement a few actions, commands, and you add
undo/redo for them you will get a better feel for the architecture.

as a side note, I tried to keep my commands purely model aware, while my
Actions work purely with editparts. This works almost 100% of the
time except the paste action since it is model aware because its pasting
models and not editparts. (since of course editparts are not the
serializable thing which holds data necessary to recreate the whole
piece-that would be the model)



--
Respectfully,


CL Gilbert

"Verily, verily, I say unto you, He that entereth not by the door() into
the sheepfold{}, but climbeth up some other *way, the same is a thief
and a robber."

GnuPG Key Fingerprint:
82A6 8893 C2A1 F64E A9AD 19AE 55B2 4CD7 80D2 0A2D

For a free Java interface to Freechess.org see
http://www.rigidsoftware.com/Chess/chess.html
Re: Non-binary connections - how do you model them? [message #160376 is a reply to message #160296] Fri, 03 December 2004 18:00 Go to previous messageGo to next message
Barry Lay is currently offline Barry LayFriend
Messages: 48
Registered: July 2009
Member
CL [dnoyeb] Gilbert wrote:

> I would say, anything that needs to be stored should be in the model.

I agree, the serialization should be entirely driven by the model.

> Also, anything which will never vary no matter what edit part is showing
> it should also be in the model. That is, you can have many edit parts
> for the same model. For instance, I have 1 editpart I use when a model
> is being edited by a particular editor, and a different editpart I use
> when the model is being displayed by another editor. Since both
> editparts count on the same location offset informatoin, I put the
> method on the model that can calculate the offset, instead of having
> each editpart do it by itself.

I don't have different editors, but I do have an outline view which has
a different structure than the graphical view, so different EditParts.

My problem now is that my "relationship" EditPart wants to place itself
based on the actual locations of the connection anchors which are at the
other ends of its connections. These anchors are positioned on the fly
in their respective getLocation methods since I wanted to line them up
with Labels within containers that use the ToolbarLayout. The actual
location of the anchors will depend on the font size of the Labels and
other rendering details that to my mind have no business being in the
model. I would like to be able, for example, to change the font for the
diagram without having to fix the model - the layout managers for the
EditParts would shuffle things graphically to ensure that the graphical
presentation displays what the model logically indicates. All the model
really knows is that this label is after that one.

So now back to my problem: I suspect that I need to position my
relationship part in its refreshVisuals method. I can get its model
easily enough and I can find the related model elements, but the
connection anchors are attached to the Figures that the EditParts own,
so either I have to push the locations of the connection anchors back to
the model when I resposition them in getLocation or somehow find the
EditParts themselves (using the EditPartRegistry, perhaps?) When the
getLocation method on the connection anchor is called I am dealing with
absolute coordinates so I am not sure exactly when this method gets
called and how often. The thought of polluting the model with transient
display details irks me. I certainly wouldn't serialize this data.

I am guessing that either I am missing a key part of the GEF design or I
am headed in the direction of a display-oriented model that gets
maintained on the fly and is separate from the business model that I
actually serialize.

Thanks again.

Barry
Re: Non-binary connections - how do you model them? [message #160392 is a reply to message #160376] Fri, 03 December 2004 20:20 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: Lamont_Gilbert.rigidsoftware.com

Barry Lay wrote:
>
> My problem now is that my "relationship" EditPart wants to place itself
> based on the actual locations of the connection anchors which are at the
> other ends of its connections. These anchors are positioned on the fly
> in their respective getLocation methods since I wanted to line them up
> with Labels within containers that use the ToolbarLayout. The actual
> location of the anchors will depend on the font size of the Labels and
> other rendering details that to my mind have no business being in the
> model. I would like to be able, for example, to change the font for the
> diagram without having to fix the model - the layout managers for the
> EditParts would shuffle things graphically to ensure that the graphical
> presentation displays what the model logically indicates. All the model
> really knows is that this label is after that one.
>

I would create this "relationship" edit part. I would make it listen
not to the connections anchors, but to the models on the other end of
the connections. When those models move, I would update the position of
the editpart. When those models are connected or disconnected from this
model I would also update its position. This "relationship" editPart
does need to store information about what connects to it, so it does
need a model of its own for this purpose only.

The model should not be bothered with the positioning of connections or
text, that is a display thing.


For instance, I have a model that does not have any display properties
itself except for position. Its size is based solely on the size of its
children. So it listens to its children (models) and when they move, it
recalculates its size. If one is added or removed it recalculates its
size and adds or removes a listener to that model. While you dont plan
to contain these other models, the net behavior is very similar. The
only data this model stores is what children it contains.


> So now back to my problem: I suspect that I need to position my
> relationship part in its refreshVisuals method. I can get its model
> easily enough and I can find the related model elements, but the
> connection anchors are attached to the Figures that the EditParts own,
> so either I have to push the locations of the connection anchors back to
> the model when I resposition them in getLocation or somehow find the
> EditParts themselves (using the EditPartRegistry, perhaps?) When the
> getLocation method on the connection anchor is called I am dealing with
> absolute coordinates so I am not sure exactly when this method gets
> called and how often. The thought of polluting the model with transient
> display details irks me. I certainly wouldn't serialize this data.
>

Yes, I think most editParts update their locations and such in the
refreshVisuals method, based on data from their model, along with
whatever other data they rely on.

Usually refreshVisuals is called as a result of some event firing
because something the editpart cares about changed. This could be the
position or size of other models. This could be due to layout
constraint changes. This could be due to a connection or disconnection
from another model.

> I am guessing that either I am missing a key part of the GEF design or I
> am headed in the direction of a display-oriented model that gets
> maintained on the fly and is separate from the business model that I
> actually serialize.
>

such a display-oriented model in GEF would be called an EditPart.

--
Respectfully,


CL Gilbert

"Verily, verily, I say unto you, He that entereth not by the door() into
the sheepfold{}, but climbeth up some other *way, the same is a thief
and a robber."

GnuPG Key Fingerprint:
82A6 8893 C2A1 F64E A9AD 19AE 55B2 4CD7 80D2 0A2D

For a free Java interface to Freechess.org see
http://www.rigidsoftware.com/Chess/chess.html
Re: Non-binary connections - how do you model them? [message #160439 is a reply to message #160392] Fri, 03 December 2004 21:34 Go to previous messageGo to next message
Barry Lay is currently offline Barry LayFriend
Messages: 48
Registered: July 2009
Member
CL [dnoyeb] Gilbert wrote:

> I would create this "relationship" edit part. I would make it listen
> not to the connections anchors, but to the models on the other end of
> the connections. When those models move, I would update the position of
> the editpart. When those models are connected or disconnected from this
> model I would also update its position. This "relationship" editPart
> does need to store information about what connects to it, so it does
> need a model of its own for this purpose only.
>
> The model should not be bothered with the positioning of connections or
> text, that is a display thing.

Here is where I am hung up. My current model has boxes with text labels
inside of them. I leave it up to the layout managers to place the
labels vertically and let the connection anchors "float" to where the
labels are by positioning them in their getLocation method. The model
knows where the boxes are and what labels they contain but it doesn't
know where the layout manager has put the text, nor does it know how big
the boxes are (since I am automatically resizing them to make them big
enough for the text). When I create the relationship part I want it to
place itself on the screen at the midpoint of the connection anchors it
will be connecting to. The model doesn't know where these are because I
have delegated all of that to the EditParts.

Here is where I am headed. The relationship part has references to the
model elements that it "relates". The relationship EditPart traverses
those elements, grabs their EditParts out of the EditPartRegistry, and
finds the screen locations of the connection anchors from the contained
Figure. The relationship location is the centroid of those points.
This way I don't need to burden the model with transient display detail.

I think that part of the problem is the GEF seems to be designed as a
drawing tool, where connections are lines that are dragged around with
the mouse and are persisted in the model. I don't want a drawing tool,
I want a graphical representation of a set of relationships. The
connections aren't real model elements anymore (since I now have a
relationship element) - they are just object references. I am not going
to let the user interact with the connections themselves as they don't
really have a standalone existence. If the user wants to get rid of a
connection they will have to interact with the relationship to tell it
to remove a reference. That is a change to its structure which I will
catch in the propertyChange method of the relationship EditPart. I will
have to listen to move events from the referenced elements (their
parents, actually) since I allow the user to drag the boxes around on
the screen.

I am trying to keep the interrelationships simple as I expect things to
get more complex as I implement scrolling and zooming and other display
customization.

Once again thanks for the discussion.

Barry
Re: Non-binary connections - how do you model them? [message #160465 is a reply to message #160439] Sat, 04 December 2004 18:51 Go to previous message
Eclipse UserFriend
Originally posted by: Lamont_Gilbert.rigidsoftware.com

Barry Lay wrote:
>
> Here is where I am hung up. My current model has boxes with text labels
> inside of them. I leave it up to the layout managers to place the
> labels vertically and let the connection anchors "float" to where the
> labels are by positioning them in their getLocation method. The model
> knows where the boxes are and what labels they contain but it doesn't
> know where the layout manager has put the text, nor does it know how big
> the boxes are (since I am automatically resizing them to make them big
> enough for the text). When I create the relationship part I want it to
> place itself on the screen at the midpoint of the connection anchors it
> will be connecting to. The model doesn't know where these are because I
> have delegated all of that to the EditParts.
>
> Here is where I am headed. The relationship part has references to the
> model elements that it "relates". The relationship EditPart traverses
> those elements, grabs their EditParts out of the EditPartRegistry, and
> finds the screen locations of the connection anchors from the contained
> Figure. The relationship location is the centroid of those points. This
> way I don't need to burden the model with transient display detail.

I believe you have crossed over into the graphic area. layouts if I am
not mistaken take place on the Figures themselves to some degree. So
perhaps you will need to extend one of the figures and create your own
"relationship" figure to be displayed by your "relationship" editpart.

For example, the movement of the wires in logicdesigner is handled by
the figure, not the editpart itself. changing color of the wire is
handled by the editpart though.

>
> I think that part of the problem is the GEF seems to be designed as a
> drawing tool, where connections are lines that are dragged around with
> the mouse and are persisted in the model. I don't want a drawing tool,
> I want a graphical representation of a set of relationships. The
> connections aren't real model elements anymore (since I now have a
> relationship element) - they are just object references. I am not going
> to let the user interact with the connections themselves as they don't
> really have a standalone existence. If the user wants to get rid of a
> connection they will have to interact with the relationship to tell it
> to remove a reference. That is a change to its structure which I will
> catch in the propertyChange method of the relationship EditPart. I will
> have to listen to move events from the referenced elements (their
> parents, actually) since I allow the user to drag the boxes around on
> the screen.
>

If you look at the example program logicdesigner, you will see that it
is not a graphical program, but one based on the logic of connections.
In fact my program is an architecture design program. Its totally
logical. All of my models have relationships to other models. some
cant exist without others. and my models are even persisted in a
database. not just persisted there, but working with the program is
working actively with database data, though graphically.

> I am trying to keep the interrelationships simple as I expect things to
> get more complex as I implement scrolling and zooming and other display
> customization.
>

Just make it work first. As you progress to implement new features you
will refactor your program to fit. That is how I did it, and I did lots
and lots of rafactoring, but I tried hard to maintain consistency with
the way GEF works. I has worked out well for me.

There is one time I deviated, and I have been having difficulty with
that part since day 1. Im going back soon ;)

> Once again thanks for the discussion.
>
> Barry

no problem. I have been working on my application for a long time, and
in GEF for probably 1-2 years. I am impressed with GEF and have never
had any lasting desire for changes in it. sometimes its overly
complicated for my app, but I follow it anyway. (like editpolicies when
I would be happy with just editparts) But in the end, it works and as
GEF adds new features, I am poised to take easy advantage of them. Also
easy to share implementations and ideas with other GEF users.

--
Respectfully,


CL Gilbert

"Verily, verily, I say unto you, He that entereth not by the door() into
the sheepfold{}, but climbeth up some other *way, the same is a thief
and a robber."

GnuPG Key Fingerprint:
82A6 8893 C2A1 F64E A9AD 19AE 55B2 4CD7 80D2 0A2D

For a free Java interface to Freechess.org see
http://www.rigidsoftware.com/Chess/chess.html
Previous Topic:Scrolling Graphical Viewer and Palette Viewer Memory Consumption
Next Topic:Automatic graph layout
Goto Forum:
  


Current Time: Thu Mar 28 09:47:54 GMT 2024

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

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

Back to the top