View source for Acceleo/Next/e4

= Introduction =
Acceleo is a code generator who implements the Model to Text tranformation language standard from the OMG (MTL). Acceleo generate codes from an EMF model with templates. It can generate any kind of source code, and you can find in the examples and tutorial some generator for Java, XML, Python, etc. Acceleo can be used in a stand alone environment to compile MTL files and to execute the code generation. You can also use the compiler and the engine with a good old java project. You can find more about the features available in Acceleo [[Acceleo/Features|here]].

= Context of the development of the prototype =
During the summer 2010, one of the member of the Acceleo dev' team started, at Obeo, to work on that prototype in order to evaluate the new Eclipse platform, e4. In order to do that we started to create a prototype of Acceleo running on e4. So first let's clarify a thing or two. E4 is the project that has been created to develop and test the technologies that will be included Eclipse 4. At the time, the first release of Eclipse 4 has been made with components of e4. This version of Eclipse 4 contained the JDT, and all the classic tools of the Eclipse platform. Those tools are the same as in Eclipse 3.6 Helios and the are running on the top of a compatibility layer. This compatibility layer allows people to run Eclipse 3.x plugins on Eclipse 4.

= Acceleo on the compatibility layer =

[[Image:Acceleo-e4-compatibility-layer.jpg|thumb|none|600px|Acceleo on Eclipse 4.0 with the compatibility layer]]

We tested Acceleo with the compatibility layer and it's fine, there were a bug or two here and there but most of the features were fully functional. The goal of that prototype is to have Acceleo running on e4 without the compatibility layer.

= Acceleo on e4 =
At the time, e4 was a nice set of APIs and frameworks but since most of the existing code of the Eclipse platform had not been ported yet to e4, there were several problems with the transition from Eclipse 3 to e4. The first and biggest problem was the fact that the bundle org.eclipse.ui had not been ported to e4. Which means, if you wanted to create some UI element you pretty much had to start from SWT/JFace widgets.

[[Image:Acceleo-e4.jpg|thumb|none|600px|The Acceleo prototype]]

And when we worked on this prototype, it was before the release of Eclipse 4.0 and there was pretty much no documentation except a tutorial or two from [http://www.vogella.de/articles/EclipseE4/article.html Lars Vogel] and some examples on the CVS like the Simple IDE from [http://tomsondev.bestsolution.at/ Tom Schindl] which was a great source of inspiration for this prototype.

= Architecture of the prototype =
Let's see the architecture of the prototype first. Since at the time, the platform was just a nice set of APIs, we pretty much had to build a complete RCP application from scratch. The base of that application had to offer the basic functions of the Eclipse IDE. For that we started to create the UI model of this basic application.

[[Image:Acceleo-e4-ui-model.png|thumb|none|600px|The handler of a command in the UI model]]

[[Image:Acceleo-e4-ui-model2.png|thumb|none|600px|A handled tool item in the toolbar]]

In e4, pretty much all the UI extension points have disappear from the plugin.xml and there are now contained in a single EMF model which describe the UI. You can see that the organization of this model allow us to manipulate all the UI concepts more easily. Since it's an EMF model you can also use all the tooling created by the modeling community. That basic EMF model allow us to describe the base of this RCP application. With this, we started to create the ui bundles of the Acceleo prototype that would contribute to this basic application. These contribution are also done thanks to an EMF model as you can see it in the next screenshot.

[[Image:Acceleo-e4-ui-fragment.png|thumb|none|600px|Contribution to the UI model thanks to a fragment]]

= UI development on e4 =
== CSS ==
Quickly after the beginning of the realization of that prototype, we decided to test some other UI technologies available with e4. First we tried the CSS. You can see in the next screenshots the prototype with and without CSS.

[[Image:Acceleo-e4-nocss.png|thumb|none|600px|The Acceleo prototype without CSS]]

[[Image:Acceleo-e4.jpg|thumb|none|600px|The Acceleo prototype with CSS]]

So let's be clear with the CSS on e4, it works, it' easy to use, it is the same old CSS that everybody knows. Yet we didn't succeed in creating something beautiful with CSS because we are not designers and we will stick with the default look and feel anyway. But for a RCP application, CSS can be a very simple way to customize efficiently the design of your application.

== XWT ==
Since we were testing the UI, we also tried XWT. XWT is not, a part of the e4 platform but since it's coming with it, we tried it at the same time. Creating the UI with a WYSIWYG editor and after that serialize it is a great idea and a WYSISWYG tool for Eclipse is a good idea, because let's face it UI code is always ugly and you can't picture the result easily.

[[Image:Acceleo-e4-ui-propertyview.png|thumb|none|600px|A custom property view realized with XWT]]

When we tested it, we were not fond of the tooling of XWT and we would have preferred something based on an EMF model. On the top of that the binding system was quite complicated. We tested it during the M7/RC1 of e4 and we didn't expected a perfect product, yet we were disappointed. It was easier to work only with the XML and then use the XWT runtime.

= Working with the new platform =
The prototype includes the Acceleo editor and some very basic features like syntax highlighting. It should be noted that working without the org.eclipse.ui bundle includes having to create an editor back from a simple TextViewer. All the nice classes like TextEditor are gone. The problem is that with the TextViewer comes lots of JFace object manipulated by their interface. Those interface are nice but since some of their implementations are deeply linked with org.eclipse.ui, you couldn't at the time have the quality of an Eclipse 3 editor with markers, auto-completion or quick fixes unless you were the guy who wrote it in the first place.

The communication with the Eclipse platform is now done in a very different way thanks to dependency injection. This change pushed us to modify some part of our architecture to go to something closer to a service based architecture. You can see here some example of dependency injection with e4.

[[Image:Acceleo-e4-dependency.png|thumb|none|600px|Example of dependency injection on e4]]

[[Image:Acceleo-e4-dependency2.png|thumb|none|600px|Example of dependency injection on e4]]

After some difficulties at the beginning, we came to the conclusion that the dependency injection is a very nice way to communicate with the platform and with other bundles. It was easy to determine where each injected value was coming from in this small environment, but we have the feeling that debugging dependency injection in a crowded environment may be a bit more painful. Anyway, some major Java enterprise frameworks switched to dependency injections years ago, it didn't kill them so we are looking forward to working with this.

We also used the new event system of equinox, the event admin, in order to send and receive events across the platform. It is one of our favorite features in e4. This is a way to replace the traditional observer pattern. Instead of communicating one with the other, the provider of the event and the listener of the event are communicating thanks to the platform and as such have no idea were the event is coming from and who is listening to the event and as such reduce the coupling of the life cycle of the provider and the listener. You can listen for an event before the creation of the provider of that event. And the provider of the event can change without trouble for the listeners. If it is well used, it could reduce the dependency between components inside the platform.

= Features of the prototype =
As you can see it the prototype possess the basic function of Acceleo with the editor, the compiler and the engine to generate code. We can create Acceleo projects and Acceleo modules and you have access to the complete Acceleo parser/compiler and generation engine. As such, you can run any Acceleo module. We didn't re-created all the views and features available in Acceleo 3 because it was a prototype and we don't intend to use this code when we will start to work on e4.

= Conclusion =
In order to sum up this experiment, we are happy with the direction that e4 it taking, even if we have some concerns that have been expressed here. Dependency injection appears to be a very nice way to interact with the platform, we will still need new ways to debug the code and to easily navigate in the dependency injection container. We also are looking forward the first version of the JDT on e4 in order to try to improve this prototype and maybe create the first elements of what could be, one day, Acceleo 4.


This feedback was presented at the "Modeling symposium" during "Eclipse Summit Europe 2010" in Ludwigsburg, Germany by Stephane Begaudeau.



{{Acceleo-index}}

[[Category:Modeling]]
[[Category:M2T]]
[[Category:Acceleo]]