You can install Acceleo and EEF from the Helios Update Site and benefit of the last features of this two projects.
For the EEF one, there is some bug fixes but mainly there is a new option in the EEFGen model that let you choose if you want use JMerge to manage user code or not. There is two way to customize generated code by EEF :
- Adding custom code in the dedicated area, protected area.
- Subclassing the generated code, putting user code in theses and providing them with appropriated provider
Arghh..I hate that blogspot loses your comments when you you click on a a link in the page. I went to look at your example and I lost everything I wrote! :/
RépondreSupprimerAnyway really glad to hear about these too important improvements. It was a bit of a pain to fnd the older version of Acceleo, and I think the JMerge is a much better option. It's a lot easier to maintain and of course it is what al of us EMF folks are used to using. I'd never used it before, but one thing I really did like about the Acceleo way was that it allows you to do protected regions in arbitrary places in the code -- this is the way XPand (what we use for AMF) works as well though I think in yet a different way. So I was pleasantly surprised when after making a major change to my EEF forms design, the code got moved from one place to an entirely different location and I don't think there is a way to support that with JMerge. In any case, I'll probably switch to JMerge just because that's what EMF uses and it will make the code more consistent.
But it would be nice to have that level of fine grained control as well. Since the design of EEF generated code is somewhat different from EMF generated code -- code blocks tend to be longer and more diverse just because of the way that SWT works -- its interesting to ponder wether the difference in code protection approaches might have implications for code generation design.
The arbitrary protected area mechanism for JMerge is a must. Please tell us when is it to be available.
RépondreSupprimer