Home » Modeling » M2T (model-to-text transformation) » <c:userRegion> vs. <java:jmerge>
|
| Re: <c:userRegion> vs. <java:jmerge> [message #51452 is a reply to message #51287] |
Wed, 01 October 2008 18:19   |
 Paul Elder
Messages: 849
Registered: July 2009 |
Senior Member |
|
|
Well:
a <c:userRegion> is just that. Text is preserved there, and there only. But
when you are editing Java code, you often need to do things like add an
import, create a new private field or method, .... If you're using user
regions, then you have to imagine each of those possibilities, and create
the user regions in your templates, and then get your users to actually put
things in those regions.
With jmerge, all of the above pretty much happen automatically.
Of course, it can be argued that you shouldn't be mixing generated code with
user-written code, especially in Java, where you can factor your generated
code so that there are clear interfaces between generated code and user
written code. The transformation might generate the latter as a user
convenience, but the understanding would be that such classes are entirely
under user control.
Paul
|
|
|
| Re: <c:userRegion> vs. <java:jmerge> [message #51507 is a reply to message #51452] |
Wed, 01 October 2008 19:05 |
Timothy Marc
Messages: 547
Registered: July 2009 |
Senior Member |
|
|
Paul,
i've worked some weeks ago with JET1 and JMerge. May be i have a wrong
imagination of JMerge, but in JET1, if have had to declare these markers
also in the Template code, just as i has to be done with the userRegion.
But what you have said sound like that the java:jmerge offers the
possbilities to declare dynamic protected regions in the generated source
and transmitting this into the newly generated, without declaring this in
the template? Is that correct?
Thx
Timothy
"Paul Elder" <pelder@ca.ibm.com> schrieb im Newsbeitrag
news:gc0evl$opl$1@build.eclipse.org...
> Well:
>
> a <c:userRegion> is just that. Text is preserved there, and there only.
> But when you are editing Java code, you often need to do things like add
> an import, create a new private field or method, .... If you're using user
> regions, then you have to imagine each of those possibilities, and create
> the user regions in your templates, and then get your users to actually
> put things in those regions.
>
> With jmerge, all of the above pretty much happen automatically.
>
> Of course, it can be argued that you shouldn't be mixing generated code
> with user-written code, especially in Java, where you can factor your
> generated code so that there are clear interfaces between generated code
> and user written code. The transformation might generate the latter as a
> user convenience, but the understanding would be that such classes are
> entirely under user control.
>
> Paul
>
|
|
|
| Re: <c:userRegion> vs. <java:jmerge> [message #51583 is a reply to message #51507] |
Fri, 03 October 2008 16:01 |
Paul Elder
Messages: 849
Registered: July 2009 |
Senior Member |
|
|
Timothy:
I'll start with a quick lesson on how JMerge works, then I'll get back to
your specific experiences...
JMerge works on symantic elements of a Java class: methods, fields, classes,
etc... Java elements that have an @generated Java doc comment are considered
updateable by JMerge. Incidentally, these elements are identify by the Java
signatures: fields by their names, methods by their names and argument
types, classes by their names, etc...
When template output is JMerged with an existing file, the following
happens:
1) Java elements marked with @generated that exist in both the template
output and the existing file are updated. (The JMerge code describes this as
a 'pull' from the template output into the existing file.)
2) Java elements in the template output that have no equivalent in the
existing file (whether or not marked with @generated) are copied to the
existing file. (JMerge calls this 'push').
3) Java elements in the existing file that are marked with @generated and
that do not correspond to elements in the template output are removed.
(JMerge calls this sweep.)
Push happens automatically in JMerge, without any rules. Pull and sweep only
happen in response to 'rule' declarations in the JMerge config file. By
default, JET uses the same rules that the EMF code generator uses.
So, with the 'out-of-the-box' JMerge rules, any method with an @generated
javadoc tag is 'owned' by the transformation and will be updated on each
update. And, any method without an @generated tag (or with a defaced tag,
such as @generated NOT or @!generated) are owned by the user, ie their
method bodies are user regions.
But, I'm guessing you have encountered situations where there has been a
'user region' embedded in an @generated method body. Something like:
/**
* @generated
*/
int foo() {
int value = 3;
// begin-user-region
// Change value here, if you want, and fear not that it will be lost
on regeneration.
// end-user-region
return value;
}
Such user regions are the result of some very fancy pull rules. The standard
EMF rules enable something like this within the javadoc comments that it
generates. And, I have done similar things for IBM products for method
bodies.
But, I honestly don't believe you need such things (at least in method
bodies). You can almost always refactor the generated code so that
user-modifiable code is in one method and 'don't touch' code in another
method. In that case, putting @generated on the ones you want the transform
to update is all you need.
Indeed, with further refactoring, you can put all the @generated methods
into a different classes. At this point, you'd hardly need JMerge at all,
unless you want to fudge on whether these 'do-not-touch' methods really are
what you say.
Paul
|
|
|
Goto Forum:
Current Time: Fri Dec 27 00:43:56 GMT 2024
Powered by FUDForum. Page generated in 0.03860 seconds |
] 
Search
Help
Register
Login
Home
