So the year 2016 has already been upon us for three weeks, and one of my resolutions is to write more blog-posts. Let’s see how this turns out…
- The target platform of my client as of now is Eclipse Luna and I am unsure if I would have been able to get GEF4 to work on Luna (there are other EMF features in the target platform used by different components, so I am not very flexible with respect to versions in the EMF field)
- Due to its maturity, there seems to be more documentation out there for GEF 3.x than there is for GEF4. For example, I have found the Kindle version of The Eclipse Graphical Editing Framework on Amazon. While this book does not contain the answer to all obstacles I came over, it contains a lot of answers and explanations, and I can recommend it as a good reference and tutorial.
In the next few blog posts, I will point out some of these obstacles which I were not able to find a solution right away, and I hope that by writing about them, and how I solved them, I will help others to find answers to similar issues faster.
So here goes–something simple to start off:
Untyped EditPart members
Well—not really an "obstacle", but I found it quite annoying that
org.eclipse.gef.editparts.AbstractGraphicalEditPart returns general types for
getModel(), getFigure(), and
I ended up with a lot of code like this:
So, I refactored my code and wrote a custom base class for my EditParts, which uses type parameters to specify the concrete types for the model, figure, and parent edit part types. Then I have overridden t he getXxx()-methods with their covariant specializations.
This makes writing things like
much more readable, because now I can write
and if you are using Xtend like me, you can even write
Plus, this common base class is a good place for utility methods. For example, I need access to the ZoomManager in several edit parts, so I also added a
More on Zooming in one of the next posts…
Here is the final EditPartBase class:
Until next time ... Happy Coding!