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

[Randy Hudson <hudsonr@xxxxxxxxxx>]

I wouldn't call this "forcing"
the node editpart to be refreshed.  This is simply what is required
given the way connections are managed in GEF.
What about creation of a new connection?
 The connection's editpart doesn't exist at that point, so something
else will have to make the node editpart refresh.

To reduce the likelihood of bugs, I
would implement all of the connection listening in one place for this type
of model.  Perhaps a single domain listener for the entire viewer,
which then uses the viewer's editpart registry to lookup the affected node,
and the calls refresh() (or a more specific method should you choose) to
"force" the update.

Another alternative would be to make
AbstractGraphicalEditPart.removeSourceConnection(...) public, so that the
management could occur from the connection editpart.  But, who would
create a new connection?

-randy

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

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

Randy,

Thanks for your reply.  I post this follow-up only for clarification.

I should perhaps have pointed out that the main reason I came across this
problem is that I am "bringing my own model" with some unique
challenges.  
It is Castor generated (www.castor.org) from an XML Schema.

In my model, "Node" and "Connection" instances are
actually siblings owned 
by the "Diagram" model, rather than parent-child "Nodes
own Connections".  
The relationship is only traversable from Connection to Node, as the Node
model does not maintain a reference to its source or target Connections.
 
This is why the NodeEditPart is not "naturally notified" on a
disconnect/reconnect, as the Node model does not change.

So, what I had to do for an interim fix is to force the ConnectionEditPart,
when notified of changes, to force an EditPart notify/refresh of first
the 
disconnected NodeEditPart then the reconnected NodeEditPart.  This
is a 
little unnatural, as I am "notifying" the EditPart of a part
of the model 
that has not changed (the Node), so that it can refresh its child 
ConnectionEditPart-s (in the forced disconnect/reconnect order).  But
it 
works.

Brett Randall

----------------

Randy Hudson wrote:
>
>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
>

_________________________________________________________________
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