Edit parts that are containers will have to implement the necessary edit policies.
The most important ones for containers are a LayoutEditPolicy (this is the one that can create the appropriate command when the user adds a child element) and a ContainerEditPolicy (which returns the command that pertains to orphaning -not sure if this is a word- children).
If you want an edit part to "do something" the first step should be to investigate what edit policies correspond most to what this "something" is. So when we need something to be done, it will involve researching the appropriate edit policy.
What edit policies do is, given a certain context, return commands that modify the model accordingly.
For example, we have an edit policy (LayoutEditPolicy) that lets you add a node on a link. The edit policy creates and returns the command that allows this. When the command is executed, the necessary edit parts are created (by GEF, not by the programmer) to reflect the model. So we just need to define the edit parts for our model elements and an edit part factory. Once that is done, GEF manages the creation of edit parts automatically.
We have a pretty good idea on how to modify the display of a connection. Therefore it shouldn't be a problem to implement connections as bezier curves. (Although we might want to explore B-splines or a different curve, since bezier curves do not join smoothly).
Our knowledge of GEF is still limited, but noticeably greater than last week. In my opinion (Jordan), we aren't quite ready to work on implementing major architecture decisions (such as a dev framework for JUCMNav) but we should be before the end of iteration 3.