Impressed by GMF, but a hefty dose of patience is required

August 22, 2007

Over the last couple of months we’ve been developing (should I say “modeling”?) a GMF-based graphical editor to support the new assembly and multi-channel, multi-tenant mediation features of Cape Clear 7.5. Actually, I’ve had pretty much no hands on involvement with it myself, a colleague of mine championed its use and has become quite expert with it, but I thought I’d pass on some of our experience. We are using GMF 1.0.3 as we are shipping with Eclipse 3.2.2 (we plan to move to 3.3 later in the year). The promise of GMF is rapidly rolled graphical editors with lots of eye candy and neat features for free, achieved with near zero code, or at least approaching zero when compared with GEF-coded editors. Our BPEL editor is GEF-coded, so we have something very substantial to compare our Assembly Editor with. Generally, I am very impressed by GMF, but much patience is required to get the best out of it. See pretty picture (a high-res version is viewable here).

GMF coded editor

Our core model is described in XML Schema and we generate our EMF model from that. A few points then:

  • This is an excellent getting started presentation.
  • It can seem like there is a huge gap between an initially generated editor (based on your model/schema) and where you know it needs to be. There may well be, but it is not necessarily a code-gap. The temptation is to jump in and start extending and modifying generated code, patience is required to do the right thing. Doing the right thing means trawling through examples and forums, posting questions to newsgroups and waiting on answers.
  • Go back to your source schema, modify and constrain it appropriately to help get the end feature the way you want in the generated editor.
  • If you have a schema that contains a lot of similar things, start with a subset of the schema which contains just one example of all the distinct elements, and get a working editor for that. Then add back in the other stuff – which is hopefully just repetition. In other words, reduce the problem space to something manageable to start with.
  • Make one model change then re-generate. The error reporting in the generation process is not very clear and diagnosing one cause and effect at once is by far the easiest way to work. Read all the error information reported and watch for compilation errors in the generated code too.
  • Make small changes to the model, regenerate and test them. When you are happy, commit those distinct changes to source control. Move on to the next task.
  • Keep step-by-step instructions for regenerating your EMF and GMF models when your schema changes, there will probably be a few manual fix-ups required (e.g. GMF 1.x doesn’t merge plugin.xml changes – 2.0 does apparently)

GMF has made it possible for us to have a great graphical editor for our Assemblies in a timeframe we would not have been able to GEF-code one in – or at least, nothing this polished and (almost) ready to ship! Hats off to the folks behind it.


4 Responses to “Impressed by GMF, but a hefty dose of patience is required”

  1. is it possible to shrink your screenshot a bit and and a href a link to the bigger version :)?

  2. codecurl Says:

    Whoops, sorry, uploaded the wrong one. Done now.

  3. btw, GMF 2.0 is lightyears ahead of 1.0… I remember that pain well.

    There’s a lot more validation and features available.

  4. After reading through this article, I feel that I need more info. Could you share some more resources please?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: