Home > Eclipse, EMF > 10 common EMF mistakes

10 common EMF mistakes

1. Treating EMF generated code as only an initial code base

EMF is a good startup kit for introducing MDSD (Model-Driven Software Development) in your project. Anyone who has been introduced to EMF and had their first code generated using EMF will for sure be impressed by the short turn around time needed to have an initial version of your model based application up and running. For many, the thrill ends as soon as you need to change the behaviour of generated code and have to dig into it and understand it. It is complex, but only complex as any other similar sized framework. Many projects I have come across make a mistake at this point. They start treating the EMF generated code as an initial code base and start making it dirty by modifying it by hand. Adding @generated NOT tags in the beginning and not anymore later. At this point you part ways with “EMF way of doing things” and also with MDSD.

The customizations mostly start with the generated editor. This is quite acceptable as the editor is intended as an initial “template” and it expects you to customize it. However, this is not the case with model and edit projects. They have to be in sync with your model and this needs making some strong decisions, specifically –  “I will not touch the generated code”. Follow EMF recommended way of changing generated code or use Dependency Injection.

2. Model modification without EMF Commands

In EMF you deal a lot with model objects. Almost any UI selection operation hands over a model object to you. It is so easy to fall into the trap of changing the state of the model objects directly once you have access to it, either using the generated model API or using reflective methods. Problems due to such model updates are detected only later, mostly when Undo/Redo operations stops working as expected.

Use EMF Commands! Modify your model objects only using commands. Either directly using EMF commands, extending them or creating your own commands. When you need to club many operations as a single command use CompoundCommands. Use ChangeCommand when you are up to making a lot of model changes in a transactional way.

3. Not reacting to notifications/Overuse of notifications

EMF notification is one the most powerful features of the framework. Any change to model objects are notified to anyone who is interested in knowing about it. Many projects decide to ignore listening to model changes and react to model changes by traversing the model again to look for changes or making assumptions about model changes and combining the behaviour into UI code.

When you want to react to a model change, don’t assume that you are the only one going to originate that change. Always listen to model changes and react accordingly. Don’t forget the handy EContentAdapter class.

On the contrary, some projects add a lot of listeners to listen to model changes without applying proper filters. This could greatly slow down your application.

4. Forgetting EcoreUtils

Before writing your own utility functions, keep an eye on EcoreUtils class. Mostly, the generic function you are trying to implement is already there.

5. Leaving Namespace URI as default

When you create an Ecore model, EMF generates a default Prefix and Namespace URI for you. Mostly this is left as it is without realizing that this is the most important ID for your new model. Only when newer versions of the model needs to be released later, people start looking out for meaningful URIs.

Change the default to a descriptive one before generating code. For example, including some version information of the model.

6. UI getting out of sync with model

The EMF generated editor makes use of Jface viewers. These viewers are always kept in sync using the generated ItemProviders. However these viewers cannot always satisfy the different UI requirements. You might have to use other SWT components or Eclipse forms. At this juncture, many implementors mix UI and model concerns together and in turn lose the sync between the model and UI.

Although, you could go ahead and implement your custom viewers, the easier way would be to use EMF Databinding.

7. Relying on default identification mechanism

Every EMF object is identified by a Xpath like URI fragment.  For example, //@orders.1/@items.3. This is the default referencing mechanism within an EMF model or across models. If you look closely you could see that the default mechanism is based on feature names and indexes. The default implementation could turn dangerous if the index order changes and the references are not updated accordingly.

Extend this to uniquely identify your model object or simply assign an intrinsic ID to your model object. EMF will then use these IDs to reference your objects.

8. Forgetting reflective behavior

Many consider the reflective features of EMF as an advanced topic. It is not as complex as it seems.

Instead of depending fully on generated APIs, think about creating generic reusable functions which makes use of the meta information every EObject carries. Have a look at the implementation of EcoreUtil.copy function to understand what I mean.

9. Standalone? Why do I bother

A misunderstanding most people have is that EMF is Eclipse specific. EMF can well run outside Eclipse as “stand-alone” applications.

While developing applications based on EMF you should design your applications such that the core is not tied to Eclipse. This would allow your applications to be run even in a non OSGi server-side environment.

10. Not reading the EMF bible

This is the biggest mistake a new comer could make. The book is a must read for anyone who starts working with EMF.

Order now (Hope this fetches me a beer at the next EclipseCON Europe ;))

About these ads
Tags: ,
  1. May 26, 2011 at 1:40 am | #1

    Great summary!

  2. May 26, 2011 at 2:15 am | #2

    Good summary. Following some additional hints.
    For the point 2, if you use EMF Transaction, modifications should encaspulated in a RecordingCommand.
    For the point 3, if you use EMF Transaction, prefer to use postcommit listeners rather than traditional adapters, to be notified only if transaction is executed successfully.
    For the point 6, using rich widgets to edit your models is made easy with EEF.

  3. May 26, 2011 at 5:00 am | #3

    Wow…! Thank you for the EMF development tips.

    I’ll make sure to remember those common mistakes :)

  4. Axel Uhl
    May 26, 2011 at 9:44 am | #4

    +1 for the notification topic. Also consider looking at the org.eclipse.ocl.examples.eventmanager bundle coming with Indigo in the OCL Examples and Editors feature. It allows clients to apply appropriate notification filters that scale. No additional cost in case your listener doesn’t get notified!

  5. May 26, 2011 at 4:39 pm | #5

    Excellent summary!

  6. Andreas Rytina
    May 26, 2011 at 4:52 pm | #6

    A great summary Nirmal!
    An other common EMF mistake which comes to my mind is to neglect performance & scalability issues. Here is a a good summary about how to improve the performance & scalability of EMF-based applications: http://www.slideshare.net/dmsteinberg/eclipsecon-2010-getting-the-most-out-of-your-models-performance-and-extensibility-with-emf

  7. May 27, 2011 at 4:24 pm | #7

    Very useful Nirmal – I feel I had to learn some of these the hard way. :-) What’s missing for me in EMF is a robust testing framework – something I plan on looking into shortly. Especially getting the Notifications right is tricky (not too many, not missing any). Anybody knows whether something like that already exists?

    Also, another pitfall is the relationship between model notifications and ItemProvider notifications.

  8. Sudarshan V
    May 29, 2011 at 4:56 pm | #8

    Perfect Summary !!!

  9. Herve
    June 3, 2011 at 10:48 am | #9

    Very great stuff, thank you ! …..

  10. Herve
    June 3, 2011 at 10:55 am | #10

    Very great stuff, thank you ! …..
    Nevertheless, I have an eleventh mistake to submit to your expertise : I would like to perform a treatment on an EMF object when I create it and I mustn’t do it again when I load the object from a saved EMF file. Up to now, I added the treatment in the constructor of the xxxImpl class in the EMF model project and I protect the treatment with a global flag set to false when I load an EMF file : it works well but I think it is not the good way to do it.
    What is your advice on that ? and do you know a better way to do it ?

    • June 3, 2011 at 10:13 pm | #11

      Thank you for your comment. Your question is more suited for the EMF forum. The real experts are there :) Nevertheless, I will try to help you.
      Could you give some more details on what kind of operation you are trying to do while the object is being created? Is it something you could do from an EMF command. If it is not necessary that this operation is done “right when the object is created”, you could listen to the notification of the EObject being attached to your model and do the operation there.

  11. January 17, 2012 at 12:40 pm | #12

    Electromagnetic area rays posseses an daunting appear whenever voiced, and lots of people, it must be an actual cause for alarm system. People are confronted with risks that they can …best emf meter reviews

  12. Vincent François
    January 24, 2012 at 6:03 am | #13

    Real table of the laws about Eclipse.

    Thank you my god !

  13. Jim
    September 13, 2012 at 5:27 am | #14

    Well said…

  1. September 8, 2013 at 7:15 pm | #1
  2. September 11, 2013 at 7:45 pm | #2

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s


Get every new post delivered to your Inbox.

%d bloggers like this: