eclipse e4 application model (EMF), XWT and XAML

When thinking about eclipse’s new e4 approach of using an EMF model to represent the “application” and thinking about the easy at which you can specify XAML, you want to draw some comparisons to help understand what problems are being solved.

The EMF-based application model in e4 represents the new way that an application is specified, potentially from different modules that are enhancements or plugins to the main application. At first glance, EMF looks like overkill (over designed) but when you draw some comparisons to how XAML works, you realize that there were reasons why EMF makes a good choice and what kind of trade-offs you have , say, compared to the easy of specifying XAML.

While the e4 team does emphasis it’s a modeled model, its not always clear why that’s useful or if it in any way matches what XAML does. Here’s a few thoughts about e4 and XAML that will be explained more in the table but are true for both

• The interface, for the most part, is specified declaratively.
  • While XAML can specify the entire interface down to a button or color, e4 only specifies the application structure mostly up to a “part” level view of an application.
  • e4 does have XWT which can pick up the ball at the “part” level and allow you to specify everything in declarative style, if you wish. There is also a Toolkit Model – TM – that allows you to use EMF as well. XWT can specify the entire application, top down in its XAML/XML declarative language. As part of e4, I would suspect that most people will use the Application model down to a “view” level then XWT from the view level down.
• The interface can be broken up into different modules and combined together e.g. a composite application or an application with multiple plugins can all contribute to the model.
  • XAML has some limitations, just like e4, on what it means to merge these different parts together during runtime or application startup.
• You can code the interfaces instead declaring them.

At the moment, XAML does provide a more consistent top to bottom model but e4’s approach emphasis other design targets, such as enterprise, module-based integration better. Overall, after building the table of comparison points below, I have a few recommendations. Its clear that the use of EMF made a trade-off between design and ease-of-understanding (at least to me) but so did XAML. Naturally, you can always write code to do things if you get stuck.

The table below provides comparison points around building applications:

#	Functional Area	e4	XAML
a	Declarative specification of your model	The *.e4xmi is a the declarative, serialized part of the model. However, the XMI specification is designed to be integrated at the model level so the XML contains many reference Ids to allow different parts of the model to refer to other parts for references as well as during merging. The tool stack uses UUIDs instead of names for these parts because the model is typically combined across many different modules and you have to ensure there are no id clashes. There are no default properties like in XAML’s XML. One could write a different serialized for the EMF model, however, that makes it easier to specify the application model manually just like in XAML but that has not been done to date. Part of what EMF offers is the ability to serialize in different ways but use the same framework to access that freeze-dried version. Its built-in. XWT is also part of the declarative approach and it’s a mostly-XAML-like implementation. It does only focus on SWT at the moment (although it can be retargeted) so the XAML-like niceties (the WPF element classes) are not available directly in XWT.	WPF uses XAML, an XML specification for the “serialized” version of the model. The XML is enhanced e.g. default properties, to make specification by hand (as well as tool) easier.
b	Separate modules contributing to the application model	e4 uses EMF’s merge model facility to merge model fragments. Because they can be merged from anywhere, UUIDs are used to specify different model elements although one can use "well-known” names. The application toplevel object for example, is called “org.eclipse.e4.ide.application” but has XMI id (for inter document references) that is an UUID. Its easy to merge models at the model element level because that’s built into EMF.	XAML handles model combining using merged resource dictionaries. You have to ensure there are no name clashes and at the same time ensure than names are easy to remember or type because XAML is much more about human readable XML that is typed by hand (although of course tooling is there) especially when referring to “application level” resources such as styles or colors. Generally though, its more difficult to merge no-style resources in XAML e.g. Commands at the top level. But there are ways around this and you can always write some plumbing of course.
c	The UI can be coded in Java/C#, sometimes you have to do that.	You don’t have to use any of the declarative approaches to specifying the application model and just write code that creates it. This just like creating the application model in Swing or any other legacy toolkit on any platform.	WPF can be fully coded in C# just like e4.
d	You can change the declarative model syntax e.g. not XML but JSON.	Since the application model is an EMF model, you could specify the model in JSON and once you have a loader for EMF, have EMF’s standard functionality load the model. This way, you don’t have to choose which declarative language you have to use, you can use any. In practice, there will probably only be a few choices for that.	WPF is really XAML driven. One could in theory of course write another loader but most likely the WPF framework is very XAML centric and there may be hidden design issues that make another specification format difficult although not impossible.
e	You can specify the interface down to any level of detail all declaratively.	In e4, you can’t do this with the application model. Its really just about resources and the application scaffolding/navigation. You could use XWT or TM to specify the rest of the model but that’s not using the same stack from the same group although XWT is part of e4 incubation.  This is an unfortunate inconsistency. Also, styling is specified in a different language, CSS.	XAML is top to bottom throughout.
f	Resources, such as colors and styling can be specifying declaratively or programmatically.	e4 uses CSS-like abilities to specify a fairly robust styling model. But its NOT the same declarative “language” as the application model (the default being XML).	XAML has resources and properties for styling that are fully specified in XAML making it fairly integrated in terms of staying with the same “language” of specification.
g	You can retarget the device/platform.	e4 has a rendering engine to render to different underlying GUI platforms although the default and the only one I am aware of is SWT—which in itself is portable mostly. A rendering engine using RAP helps render to the web and Flash.	This one is a bit more tricky. The framework of XAML and components in WPF are not really unified in that different components are specified in the XAML for different targets e.g. Silverlight versus WPF. But the component's have properties and names that are almost the same if not the same so it feels like it can render to different devices directly. The architecture, according to MS documentation, is designed to have a backend rendering framework so conceptually this is just like e4.
h	Data binding directly in the declarative specification.	In e4, using XWT for the button/textbox level specification, it has data binding support. Its not as robust as XAML in the sense of specifying source targets, traversing the UI tree to find sources, etc. but there is support there. Overall, if you look at how you bind, in some cases, e4’s DI framework makes up for cases where you need to inject into objects. However, this is not data binding in the same spirit. Underneath there is eclipse data binding which exists. I found the data binding in eclipse to be more programmatic and difficult to use. Part of this is around Realm specifications, part is because the framework had to be agnostic to the end points. XAML could assume DependencyObjects. Eclipse data binding could not, so its more engineered and more complex, but that was the problem and environment it needed to address. XWT simplifies this quite a bit and in general, if you are doing something on your own, you always need a lot of helper classes (some are included in eclipse of course) to use it while avoiding syntax heavy coding.	XAML has a rich databinding that centers on property notification and DependencyObject management. DependencyObjects (all UI elements descend from) provides a rich property system. Inherited properties default, local values as well as a general untyped interface enable a variety of data binding scenarios. Some people find the databinding in XAML confusing but this is the same type of confusion that exists with e4’s XMI specifications and EMF approach. Databinding in XAML tries to address a difficult problem. Sometimes you have to specify the the source object is somewhere in your visual tree, you don’t know exactly where, and you need to bind to that object. So there is data binding support for finding UI elements by their type, or the UI element that is the template parent, etc. Once you realize the problem its trying to solve, the approach makes sense for the framework and works remarkably well.
i	Templates to make customization easier in various ways. Templates are like a defmacro in lisp, at least conceptually, or a “Provider/Factory” in jface that provides UI elements for display in some control.	TBD. Instead of templates, think instantiating model elements??? Need more research on his issue.	XAML has a template concept that works with the UI elements. It can all be specified in XAML. It includes template controls whose contents are defined by templates, items list whose data for each item is template. A template either says “display the control this way and put the  main content HERE” or “given this data of type X, I want UI elements to be generated using this data template.”
j	Dependency injection	e4 provides dependency injection and some forms of lifecycle management for the objects instantiated as part of the model. It supports multiple JSR’s on DI.	XAML is beginning to look more and more like a DI container. It now can specify constructor args for objects it creates. It also can reference other objects in the XAML context, etc. It does not do dependency inject in the same way as full DI containers but in general you can think of it as property injection.
k	Adding properties and methods to UI components in your application	e4 is a modeled application so you can bring up the basic model, add properties, method, etc. then regenerate the classes.  EMF makes sure that the code that’s there does not change so essentially you can extend the core model if you wish and its not that hard. Of course you could always use AspectJ. You can also implement something like dependency properties as well. It’s a bit more involved to change the basic model though so I’ll claim that this as more advanced activity. Since its EMF, any properties you add to the objects provide change notification.	XAML allows extension of properties through dependency properties. In fact, extensive behavior modification can be made by making small class that declare dependency properties and then these are attached to the object. It works quite nicely as an extension approach without a lot of work such as changing a core model as in e4, but its not quite the same as having an actual property. In this sense, dependency projects are like lisp properties on objects with the added benefit that that can be databound and have change notification. Also, the .net platform has partial classes but most of the MS supplied classes are close already. C# has recently introduced static methods called extension methods that make extension of existing objects easier syntatically although the extension methods cannot access internal non-public state.

So overall, there are really a lot of similarities. e4 has a lot of other features as well but so does WPF. Both XAML and e4’s container concept are converging a little to the Dependency Injection/container thinking. XAML can specify constructor args, e4 can specify lifecycle and injection, etc. So there are similarities that are converging.

I think XAML is more consistent from top to bottom but it makes some, although I think small, trade-offs to do that. You have to decide which set of trade-offs work for you of course. I think the classic eclipse case, there is a lot of engineering but the easy stuff is still hard to do for beginners. Here’s some recommendations for the e4 team:

1. Make the modeled stack consistent top to bottom and ensure its seamless. Right now the application model kind of stops at the “part” level in a sense.
2. Stop talking about the modeled application. Do start emphasizing that its declarative and programmatic. Emphasize the use cases that a modeled application model actually helps with e.g. integrating across modules just like the old approach—but leave “EMF” out of the conversation. This recommendation is really about product marketing but I think it would help programmers commit to the learning curve needed to use e4 and provide some comfort that what is being done is done for a reason.
3. Create a EMF model serialization format that is easier to specify manually like XAML. You can use JSON or XML or whatever, but it would be nice to have something easier more akin to XWT. This would also cut down on your need for advanced tooling to specify the model.

Is a modeled approach better than XAML, which models only XML? Its not clear that it’s a better-than-this answer, only that different trade-offs have been made.