Galileo: Improved EMF-Databinding-Support

i’m happy to announce that emf-2.5 will come along with support for the brand new eclipse-databinding api coming with eclipse-galileo. a big kudos goes to matthew hall who reviewed my patches and helped me shapeing the support and it’s documentation ( more in bug 262160 ).

i got voted in some weeks ago as a committer on emf and so now i’m in charge of the databinding-support for emf and i’ll try to fix problems with the api and give answer to questions on the newsgroup.

before i start explaining some nifty and nice things about the api and how one can use (and probably extend) it let me state that the api is marked as provisional and there are chances (though small ones) that we’ll introduce a breaking api change in the next release.

this is going to be a series of blog postings showing some new emf-databinding stuff in action:

• part 1: create the domain-model
• part 2: introduce the new properties api
• part 3: setting up a treeviewer with emf-databinding
• part 4: using the properties api in master-detail
• part 5: setting up a tableviewer with emf-databinding
• part 6: write your own property for unsupport widget-types
• part 7: make the storage system plugable

to give you a possible jump-start on emf-databinding i’ve been working on an example application in the last few days.

all example code is available from eclipse-cvs and released under epl.

creation of the domain-model

before we can start with the domain model for our application we need to know
what the model is going to be for. so let me explain the application we are
going to write in this blog series:

suppose the eclipse foundation hired you to write an application which allows them to administrate their committer and project metadata.

we now need to create a domain model of this minimal information given
which could potentially look like this:

let’s take a closer look on the domain model objects:

• foundation
  
  the root of the domain model is the foundation which has 2 list properties:
  • projects: top level projects like emf, technology, platform, …
  • persons: persons who take a part in one ore multiple projects
• project
  
  an eclipse project has many different properties from the project start to the project end date to the url of the homepage. the most interesting ones are:
  • subprojects : a project can have subprojects who can then itself have subprojects
  • parent : a project has one parent pro ject (beside the top-level ones) – this means projet-subprojects relation is modeled as a bidirectional relationship
  • projectleads : a projet can have multiple project leads
  • committers : a project has multiple committers
• committership
  
  people who are committers on a project get a so called committership which has a start and end date. the most interesting of them are:
  • project : the project the committership is for – this means once more that the committership-project relation is modeled as a bidirectional relationship
  • person : the person who holds the committership
• person
  
  the “real” person who gets committer or project lead on a project. the field of interest here is:
  • committerships : which holds all committerships a person has this means that the committership-person relation is also once more modeled as a bidirectional relationship

to get a highlevel overview above the model and how the classes are related together the class-diagram helps a lot:

as you noticed i modeled many of the relations as bidirectional relations. this is not strictly need everywhere because some of the relations like project-subproject have an implicit parent relation because they are containments and hence econtainer() could be used to access the parent. still when it comes to databinding such a containment relationship doesn’t help because there’s no feature you can use to navigate from child to container but only the call to the method econtainer().

emf also provides an editor to create an instance of your ecore-model and save it to xmi which makes it easy for us to create test data. an example of an xmi looks like this:

from http://tomsondev.bestsolution.at