Re: [gef-dev] EditPart-s Refresh Order Critical on Connection Model Chan

[Randy Hudson <hudsonr@xxxxxxxxxx>]

It sounds like a notification glitch
in your model, or a problem with the command performing the reconnect.
 The way your model is notifiying, it indicates there is a transitional
state in which the connection originates (or terminates) at 2 different
nodes at the same time.  Does your model really support this state?

If your model was an exact parallel
to the editparts, and if you generate that model with EMF, for example,
the generated model would ensure the order of notification that we expect.
 But, of course, we don't make such a requirement, so I suppose we'll
have to handle this scenario.  Open a bugzilla.  But, I'd also
go back and look at your commands that you are creating, and see if you
can't first disconnect the connection, and then connect it to its new terminal.

For re-parenting object, we separate
the process into "orphan" and "add".  If we had
done the same thing for reconnect (separate into "disconnect"
and "connect"), this might be better at enforcing the preferred
order of events.

-Randy

"Brett Randall" <brett_s_r@xxxxxxxxxxx> Sent by: gef-dev-admin@xxxxxxxxxxx 11/01/2003 08:01 PM Please respond to gef-dev

To:        gef-dev@xxxxxxxxxxx         cc:                 Subject:        [gef-dev] EditPart-s Refresh Order Critical on Connection Model Change

GEF 2.1.1 on Eclipse 2.1.1

I have recently had a problem with the refresh of EditPart-s following
a 
ConnectionEditPart reconnect (Model change).  I am raising it here
to test 
support for changing a particular behaviour of AbstractGraphicalEditPart.

My observation is: When refreshing the EditPart-s of connected nodes, 
following a Model change which is either a Source or Target Connection
reconnection, unless the disconnected node's EditPart is refreshed before
the reconnected node's EditPart, the ConnectionEditPart for the changed
connection is corrupted (it loses its new Source or Target).  In other
words, you cannot treat the Model-Controller notification of a connection
change as an atomic unit, rather separate notifications of first the 
disconnect and then the reconnect are required.

If for whatever reason during the Model change the new node for the 
Connection is refreshed first (perhaps due to a CompoundCommand), the 
ConnectionEditPart will be corrupted.

I tracked this down to the way that 
AbstractGraphicalEditPart.removeSourceConnection(ConnectionEditPart)/removeTargetConnection(ConnectionEditPart)
(called from refreshSourceConnections()/refreshTargetConnections() in the
EditPart of the node) maintains the bi-directional navigability between
an 
EditPart and its ConnectionEditPart-s :

from AbtractGraphicalEditPart.removeTargetConnection(ConnectionEditPart)
:

protected void removeTargetConnection(ConnectionEditPart connection) {
fireRemovingTargetConnection(connection, 
getTargetConnections().indexOf(connection));
connection.setTarget(null);
primRemoveTargetConnection(connection);
}

The first call is for listener notifications, the setTarget(null) is to
set 
the (being removed from this node) ConnectionEditPart's target to null
(the 
link from ConnectionEditPart to the node EditPart), and the third call
removes the ConnectionEditPart from the node's Collection of target 
connections (the link from node EditPart to ConnectionEditPart-s).  The
connection.setTarget(null) causes me a problem if the ConnectionEditPart
that is being removed from this node has already been refreshed, and 
therefore its Target is already set to the new target node, which is 
replaced by null with this call.

Proposed change: could wrap the call to connection.setTarget(null) with
if(connection.getTarget() == this), preventing overwriting of the 
connection's new target in the event that it has already been refreshed.

This applies also to AbtractGraphicalEditPart.removeSourceConnection.  As
an 
aside, this method contains an additional call to connection.deactivate()
- 
should a Connection be deactivated just because it is being removed from
this node?

Thoughts, comments welcome.

Brett Randall

_________________________________________________________________
Hot chart ringtones and polyphonics. Go to  
http://ninemsn.com.au/mobilemania/default.asp

_______________________________________________
gef-dev mailing list
gef-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/gef-dev