Thursday, January 17, 2008

A Quick Eclipse-based XML Editor Using EMF, Part I

Introduction

I've recently been dabbling in OSGi technology and found DS (Declarative Services) feature neat for automagically registering and finding/consuming services. Basically, instead of having to call OSGi APIs for registering Java objects(services), you will just need to "declare" these provided services in an XML file and the DS framework will take care of registering it for you. Similarly, if your application needs a service, instead of finding (and tracking) it yourself in code, just declare it in the XML file and DS will take care of "injecting" it into your object and tracking dynamic registration/unregistration. It is very reminiscent of Spring Dependency Injection and in fact, Spring has a very similar technology called Spring DM (Dynamic Modules). In the end, these technologies are all about decoupling your business logic from framework/container (e.g.OSGi) APIs, which promotes greater code reusability.

Anyway, like I said, the configuration is XML-based and being the lazy (in a good way ;-)) developer that I am, I wanted an integrated editor in Eclipse to edit these DS files. Nowadays, whenever I see and XML<->Java binding (plus Eclipse integration) problem my neurons automatically fire "EMF!", and so I set about trying to use this technology to create my own editor.

Which brings us to our first box-looking thingie:

What is EMF?

  1. A (meta-)modeling language (ecore)
  2. A Java code generator for your model
  3. An (extensible) XML<->Java binding framework

In addition to the above, you also get the following:
  • Reflective API (e.g., eGet("sandwich") method in addition to getSandwich() method)
  • Change notification
  • Base adapter & adapter factory classes for most model editing needs (providing content, labels, etc. for your model)
  • Command-based editing, undo/redo support
  • A sample Eclipse editor which you can customize or study
  • An option to export the editor as a standalone RCP app (cool!)


As a modeling technology, EMF is pretty solid and feature-rich. However, for this case, we don't need to create models because there is already a schema available - it's in the OSGi specs. EMF already has the ability to convert any XSD schema to an ecore model, and vice-versa.

The DS schema looks something like this:


I just copied it from the specs and saved it to a file in my system.

Here, then, is the quick procedure for creating the editor. Are you ready? Don't blink your eyes because this will be F-A-S-T! :-)

1. From Eclipse, click New->Other..., then select EMF Project as below:


You will be prompted for a project name. Type, e.g., org.example.ds.

2. Select a Model Importer. For now we use XML Schema:


Then, browse to where you saved the DS schema file (.xsd).



3. In the next page you will be asked what packages to import. EMF tries to generate a model filename from the schema contents but it's sometimes not nice (e.g. _0.ecore). You can rename it if you want, like here I renamed it to ds.ecore.


4. When the wizard is finished, you will have a new project in your workspace, with the generated ecore model (ds.ecore). Also, there will be a ds.genmodel file which is a generator model for your model: it tells EMF about code-generator-specific stuff like where to put the generated files, what base package name to use, etc.

You can view and edit these files via the Ecore and GenModel editors already bundled with EMF:



Again, the package name derived from the schema might not look nice ("_0"), so here we can rename it. In the Ecore editor, select the package _0, and in the Properties View, set the Name property to "ds".


5. Now that that's out of the way, we can configure the code generator. First, double-click the ds.genmodel file. It will open the GenModel editor:


We can set the Base Package property to org.example so that the generated package will start with org.example.ds. And also rename the Prefix property to "Ds" (previously it was "_0").

6. Code generation time!

Select the root genmodel (Ds), right-click, then click the Generate Model Code, Generate Edit Code, and Generate Editor Code commands successively.


If successful, it will generate the Java code for your model, as well as 2 new projects: a UI-agnostic .edit project which you can re-use outside of the Eclipse environment, and an Eclipse-specific .editor project which is tightly bound to (you guessed it) the Eclipse environment.

The editor application is complete!

7. You can test it by launching a new Eclipse instance from the workbench:


It will run a new Eclipse environment with your core, edit, and editor plug-ins included. In it you can try to create a new DS file via New->Other...->Example EMF Model Creation Wizards->Ds Model.


If you try to double-click this new file, it will invoke the .editor plugin you just created, and show a nice tree-based editor for you!


The great thing is, if you try to look at My.ds using a text editor, you will see the underlying data is fully compliant XML!


What's Next

We've gone from zero (editing XML by hand) to hero (editing the same XML by a neat, integrated, GUI-based editor) in just a few mouse clicks. But that is not all that EMF can do! I just hope this article has gotten you interested enough to want to have a deeper look. :-)

From here, where can our DS Editor application go? Well, I can see a few things for improvement already:

1. The generated class names are ugly!

Did you have a look at the generated model/Java code? There are classes whose names are Tservice, Tproperties, and so on (fugly!). These are a direct consequence of the <complexType name="xxx"> declarations in the schema. It would be nice if the generated class names were more, hmm... how you say... Java-ish? :-p Like Service and Properties, respectively, for example.

In the next parts I will show how to "coax" EMF to generate (nicer, if you wish) class names, so you won't be forced to use the schema's type names if you don't want to. :-)

2. I want more Eclipse IDE integration!

For example, when I edit the attribute interface, I don't want to type the Java interface name in a text box. I want something similar to those nice JDT dialogs where I can search and select for the Java interface:


In the next posts, we'll see how this can be done.

3. I want it to make me coffee & toast!

Okay, EMF is cool.. but not that cool :-)

Stay tuned!!!

2 comments:

C├ędric Vidal said...

That's cool :) Looking forward to the interface selection dialog ;)

sud said...

Thanks for this tutorial. Has part II been posted?