Decorating with EMF

I recently added something totally cool to EMF.  It's so cool, you might want to use it even if you don't use EMF for anything else.  You're probably aware that JFace provides tool tip support for column viewers and of course, as a user of JDT, you've likely made extensive use of the Java editor's Javadoc hovers which display HTML-based information that even allows hyperlink navigation.  It's effectively a mini browser.  With the new feature I added, you can easily display HMTL-based hover information in any column viewer. You can see that in action with the sample I created; you'll need the latest build.  It's an RCP application that looks like this:

It displays a simple hand-written file system "model" where the files have links to other files. The hovers allow you to navigate those links within the tree. Note that EMF ships with many fine-grained features, so you need only depend on EMF's Common UI feature to exploit this, i.e., just two very small plug-ins, not the whole EMF runtime.

I used this basic feature to implement improved validation support. You can try this out by enabling Sample Ecore Editor → Live Validation.  With that enabled, whenever you change the model, the tree view will be decorated with validation results.  For example, when you create a new EClass, it won't have a name, and that's invalid.  The hover displays that as follows:

Note that the validation decorations propagate up the tree. The hovers at these higher levels display a composed result which contains links to allow you to navigate directly to any child object with a problem.

Also, the properties view itself is decorated, so a feature with a problematic value will be called out and selecting it provides details in the status line.

Pretty cool hey? And now for the best part: this has all been generated.  So if you'd like to see this type of thing in your own model, just set the GenModel's Editor Decoration property to Live, regenerate the editor, and enjoy the results. Have a look at the underlying infrastructure and let your imagination run wild with creative ideas of your own.

I'd like to thank itemis, the generous sponsor of cool things, for funding this year's "Christmas tree decoration" effort. The benefits will definitely outlast your decorated Christmas tree.

EMF Can Do What?

I've been very busy these past months implementing all kinds of cool new things. Of course I always intend to do some marketing for them, but once each problem is solved, it loses its glitter and I quickly focus on the next cool thing.  I know I really should take time to make the community aware of new capabilities, because it makes those things more valuable in reality, but I still prefer to focus on development.  Oh well, we all know where the road paved with good intentions typically ends.

As an example, I'll bet very few people are using using a ResourceSetImpl.ResourceLocator, something I added in EMF 2.8, because they don't know they can. You can see how it's used in the unit test, i.e., just create it and you're done.  What does it do? It allows ResourceSet.getResource to find the resource without searching the whole resource set.  If you look closely at how it's normally implemented, you can see it uses quite an expensive linear search that is made even more costly by the need to normalize each resource's URI to do proper comparison.  By adding a locator, the cost reduces to a fast mapped look-up where the performance is independent from the size of the resource set. Most importantly, the map is properly maintained, so no matter what you change, including changes to the URIConverter's URI mappings, you'll always find the right resource in constant time.  So if your application has a large number of resources, your should consider using it.

The most recent example of a cool new feature is support for reified types. You'll only notice this change if you use generics extensively and you regenerate your model, assuming I've not broken anything in the process, because then you might notice sooner!  Consider the following model:

Notice that in menu we know the children and selected element should be menu elements. With the latest build, the generator realizes that too, so it generates the following overrides in the menu's implementation class.

In other words, the generator will ensure fail-fast, type-safe behavior.  Not only that, the edit support is also enhanced.  That is, you can create any type of thing in a container.

But you can create only a menu element in a menu.

Similarly, you can select any type of element in a container.

But you can select only a menu element in a menu.

How cool is that?  You might ask yourself, who would model in this way?  Look closely, you'll find it right under your nose.  I have the good intention to blog about other cool things you probably didn't realize were available.