Difference between revisions of "Acceleo/Next/e4"

From Eclipsepedia

< Acceleo‎ | Next
Jump to: navigation, search
m (Acceleo on e4)
m (categories)
 
(4 intermediate revisions by one user not shown)
Line 30: Line 30:
  
 
= UI development on e4 =
 
= 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.
 
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.
  
Line 38: Line 39:
 
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.
 
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.
  
Since We were testing the UI, we also tried XWT. XWT is not, I think, a part of the e4 platform but since it's coming with it, I tried it at the same time. I've always loved the idea of creating the UI with a WYSIWYG and after that serialize the UI, because let's face it UI code is always ugly and you can't picture the result easily. I was not fond of the tooling of XWT and I would have preferred something based on an EMF model butit worked even if the binding system was quite complicated. I am not sure that I will use it again but with improvements, I would gladly try it again. The property view, here has been created with XWT.
+
[[Image:Acceleo-e4-ui-propertyview.png|thumb|none|600px|A custom property view realized with XWT]]
  
= First look at the prototype =
+
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.
So here you can see the prototype running, with the editor and some very basic features. I would like to point out that working without the org.eclipse.ui bundle includes having to create an editor back from a simple TextViewer. All the nice classes like AbstractTextEditor are gone. The problem is that with the TextViewer comes lots of JFace object manipulated by their interface like the annotation model for example. Those interface are nice but since their only implementation is in org.eclipse.ui, you cannot have the quality of an Eclipse 3 editor with markers, auto-completion or quick fixes unless you are the guy who wrote it in the first place.
+
  
 
= Working with the new platform =
 
= Working with the new platform =
The communication with the Eclipse platform is know 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. After some difficulties at the beginning, I have to say 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 I 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, personally I loved it in e4.
+
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.
  
I 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 my 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. If it is well used, it could reduce the dependency between components inside the platform. My only fear was to overused it.
+
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 =
 
= 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. During this small demonstration, we will create a small Acceleo project, in this project we will have a very small template (it is not a demonstration of what Acceleo is capable of after all) and then with this small project and with a small EMF model we will generate a small html page describing each EClass of the model.
+
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 =
 
= Conclusion =
In order to sum up this experiment, I would like to say that I am looking forward working on e4. Dependency injection appears to be a very nice way to interact with the platform. I am looking forward the first version of the JDT in order to try to improve this prototype and maybe create the first elements of what could be one day Acceleo 4.
+
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}}
  
This report was presented at the "Modeling symposium" during "Eclipse Summit Europe 2010" in Ludwigsburg, Germany by Stephane Begaudeau.
+
[[Category:Modeling]]
 +
[[Category:M2T]]
 +
[[Category:Acceleo]]

Latest revision as of 07:03, 12 January 2011

Contents

[edit] 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 here.

[edit] 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.

[edit] Acceleo on the compatibility layer

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.

[edit] 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.

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 Lars Vogel and some examples on the CVS like the Simple IDE from Tom Schindl which was a great source of inspiration for this prototype.

[edit] 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.

The handler of a command in the UI model
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.

Contribution to the UI model thanks to a fragment

[edit] UI development on e4

[edit] 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.

The Acceleo prototype without CSS
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.

[edit] 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.

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.

[edit] 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.

Example of dependency injection on e4
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.

[edit] 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.

[edit] 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 Portal
Project Project · Installation · New & noteworthy · Release review · API policy · Retention policy · Next · Checklist
Features Acceleo Features · Runtime · Acceleo editor · Views & Perspective · Debugger · Profiler · Traceability · Wishlist · Interpreter · Maven
User documentation Getting Started · Acceleo operations reference · OCL operations reference · Text Production Rules · Migration From Acceleo 2.x · Best Practices · Videos · FAQ
Developer documentation Source code · How to contribute · Compatibility · MOFM2T specification · OCL specification
Community Conferences · Twitter & Blogs · Professional Support · Report a bug