[gef-dev] EditPart-s Refresh Order Critical on Connection Model Change

["Brett Randall" <brett_s_r@xxxxxxxxxxx>]

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