Galileo: EMF-Databinding – Part 1


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:
Screen shot of the Ecore-Editor
Let’s take a closer look on the domain model objects:

  • Foundation
    Foundation Class
    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
    Project Class
    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
    Committership Class
    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
    Person Class
    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:
Ecore-Class-Diagram
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:
XMI-File

About these ads

7 Responses to “Galileo: EMF-Databinding – Part 1”

  1. Hi Tom,

    great work! I like the example.

    You say “there’s no feature you can use to navigate from child to container but only the call to the method eContainer”. Wouldn’t it make sense to add support for this to the EMF data binding?

    Michael

    • I already thought about it – the main problem is that there’s no event when reparenting elements IIRC but we could definately take a look at this in 2.6 to see if we can provide such a feature.

  2. Very useful. I have a thorny issue though: How do you use this if there is no feature from the source to the target, only in the reverse direction? I.e. you want a->b (0..*), but the ecore only contains b->a(0..1) I am not sure how to implement the ObservableFactory under these circumstances.

Trackbacks/Pingbacks

  1. Galileo: Improved EMF-Databinding-Support « Tomsondev Blog - June 6, 2009

    [...] Part 1: Create the Domain-Model [...]

  2. 2010 in review « Tomsondev Blog - January 3, 2011

    [...] Galileo: EMF-Databinding – Part 1 June 20093 comments 5 [...]

  3. 10 common EMF mistakes « Nirmal's Blog - May 25, 2011

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

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

Follow

Get every new post delivered to your Inbox.

Join 597 other followers

%d bloggers like this: