| What is the best practice to keep the generated and handmade code in separate files ? [message #630440] |
Sat, 02 October 2010 10:33  |
Eclipse User |
|
|
|
Hi
I have a requirement to keep the generated and handmade code in a separate java files (in separate source folders). What I want to achieve is that it should be possible to delete all generated code and regenerate it again from an ecore model while keeping all handmade code untouched.
That is, I would like to extend a generated class AGen with a class AImpl extends AGen, override some of the methods of the AGen (for example all derived features) or provide implementation of new methods. Further, I want to use AImpl class in the generated .edit and .editor code.
For that purpose, I annotated my ecore model attaching
annotation source="mysource"
key="extendingClass" body="SomeExtendingClassName"
to each EMF class that I want to extend.
Next, I changed the template for the generation of the Factory class to create my extending class instead of the class defined in the ecore model, for example
AGen createAGen() {
...
AGen aGen = new AImpl();
return aGen;
...
instead of
...
AGen aGen = new AGen();
return aGen;
...
I use the same approach to separate the generated and the handmade code of the ItemProviders in the .edit plugin.
Are there any issues with this approach? Is there a better way to keep the generated and handmade code separately while being able to reuse all the generated code for .edit and .editor plugins?
Regards,
Stanislav
|
|
|
| Re: What is the best practice to keep the generated and handmade code in separate files ? [message #630445 is a reply to message #630440] |
Sat, 02 October 2010 11:53  |
| Eclipse User |
|
|
|
Stanislav,
Comments below.
Stanislav wrote:
> Hi
>
> I have a requirement to keep the generated and handmade code in a
> separate java files (in separate source folders).
Sounds like
http://ed-merks.blogspot.com/2008/10/hand-written-and-genera ted-code-never.html
> What I want to achieve is that it should be possible to delete all
> generated code and regenerate it again from an ecore model while
> keeping all handmade code untouched.
You might look at how the Xtext folks manage this.
> That is, I would like to extend a generated class AGen with a class
> AImpl extends AGen, override some of the methods of the AGen (for
> example all derived features) or provide implementation of new
> methods. Further, I want to use AImpl class in the generated .edit
> and .editor code.
That's not directly supported by EMF's generator.
>
> For that purpose, I annotated my ecore model attaching
> annotation source="mysource"
> key="extendingClass" body="SomeExtendingClassName"
>
> to each EMF class that I want to extend.
>
> Next, I changed the template for the generation of the Factory class
> to create my extending class instead of the class defined in the ecore
> model, for example
>
> AGen createAGen() {
> ..
> AGen aGen = new AImpl();
> return aGen;
> ..
>
> instead of ..
> AGen aGen = new AGen();
> return aGen;
> ..
>
> I use the same approach to separate the generated and the handmade
> code of the ItemProviders in the .edit plugin.
>
> Are there any issues with this approach?
Sounds okay. I've suggested in the past that we could provide a feature
that basically is only the sweep phase of our merging step--- it would
leave behind only the non-generated artifacts---but purists will always
need to be even more pure than that.
> Is there a better way to keep the generated and handmade code
> separately while being able to reuse all the generated code for .edit
> and .editor plugins?
It's fine, but I wonder what are the big advantages of this additional
complexity? Mint already provides filters that let's you view just the
non-generated stuff so the need for actual physical separation seems
marginal.
>
> Regards,
> Stanislav
|
|
|
| Re: What is the best practice to keep the generated and handmade code in separate files ? [message #630479 is a reply to message #630445] |
Sun, 03 October 2010 03:04 |
| Eclipse User |
|
|
|
Stanislav,
I did not read all of yours and Ed's post. But I can recommend you a
little tool called eJava. With eJava you can model the implementation of
eOperations of your metamodel in seperate files. This behavior model
will be specified with a textual syntax based on the Java metamodel. So
it feels like implementing Java. After implementing the behavior it will
be woven into the ecore file as body annotation. Then the EMF generator
will recognize it and generate the operation's bodies. As you can see
the specification and the static model can be kept separate. Just hava a
look at [1] and try it out. If you have problems just contact the
developers via the contact link on that page.
best regards
Jan
[1] http://www.emftext.org/index.php/EMFText_Concrete_Syntax_Zoo _eJava
|
|
|
Powered by
FUDForum. Page generated in 0.04131 seconds
Home