| [JET] Protected Areas [message #513866] |
Thu, 11 February 2010 14:37  |
 Siegfried Nolte
Messages: 48
Registered: August 2009 |
Member |
|
|
Hi JET folks,
I did a JET generation of some code. I changed the generated code in some points. Now the model has changed and I want to generate again into the existing code files. How can I protect my self done changes within the target files?
Thanks,
Siegfried
[Updated on: Thu, 11 February 2010 14:37] Report message to a moderator |
|
|
| Re: [JET] Protected Areas [message #514118 is a reply to message #513866] |
Fri, 12 February 2010 13:36  |
Paul Elder
Messages: 849
Registered: July 2009 |
Senior Member |
|
|
Siegfried:
With JET, you have several options.
Java files
First, for Java files (.java and .properties), you can make use of JMerge, which is the technology EMF uses in its generated code. The recipe for using JMerge in a Java file is simple:
1) put @generated Java doc tags in Java elements you want to be the code generation to update. Example:
/**
* ... standard Java doc you want to generate ...
* @generated
*/
int foo() {
// default implementation of foo...
}
To be clear, you put these in your JET template.
2) insert a tag in the JET template.
3) Give your code generator users the following rules:
i) If you want to edit a method with an @generated tag, remove or deface the tag, too. Some common methods of defacing the tag: ,
ii) You can add any Java elements to like to a generated class (so long as they don't have an @generated). They will not be modified or removed.
You can use in a properties file, too. In this case, there are no @generated tags. The basic rules are:
i) existing properties are never modified or removed by JMerge
ii) new properties (defined by the executing template) are added
Non-java files
For non-java files, JET offers a mechanism for designating parts of the template out as user editable. This is done through the and tags. An example:
<c:iterate select="$class/setter">
public void ${@methodName}(${@type} ${@var}) {
<c:userRegion>// BEGIN: ${@methodName}(${@type} ${@var})<c:initialCode>
// TODO: code method
</c:initialCode>// END: ${@methodName}(${@type} ${@var})</c:userRegion>
}
</c:iterate>
If you had a model something like this:
<class ...>
<setter methodName="setFoo" type="String" var="foo"/>
<setter methodName="setBar" type="boolean" var="bar"/>
</class>
Then, you would expect output like this:
public void setFoo(String foo) {
// BEGIN: setFoo(String foo)
// TODO: code method
// END: setFoo(String foo)
}
public void setBar(boolean bar) {
// BEGIN: setBar(boolean bar)
// TODO: code method
// END: setBar(boolean bar)
}
The user would then be able to safely edit code between each BEGIN and END comment.
JET user regions can be applied to any type of output, but they are less flexible than JMerge. In particular, be aware that:
i) white space counts between <c:userRegion> and <c:initialCode> - it is a best practice to keep such whitespace to a minimum (or avoid altogether). In particular, avoid tabs or new lines.
ii) the tags cannot preserve user regions that are no longer generated. For example, if the 'setBar' method was removed from the input, then the setBar method would not be generated in the output, and the contained user region would be lost.
Alternatives to merging code
Before you embark on heavy use of user regions or JMerge, you should give some thought to the structure of your generated code. Many times you will serve your user better by separating user-editable output from output that the user should not touch.
I put my generated output into the following categories:
* generator owned - the user may look, but shouldn't touch this content. The generator will replace it every time.
* user owned - the generator may create the file (as a convenience to the user), but it will never modify existing content.
* shared content - both the user and the code generator can update this content.
Shared content is where you employ JMerge or user regions, but generator owned and user owned are much easier for users to work with.
On the implementation front, you implement each of these as follows:
* generator owned - use standard ws:file, java:class or java:file tags
* user owned - use standard ws:file, java:class or java:file tags with the attribute
* shared code - use standard ws:file, java:class or java:file tags, and include either java:merge or c:userRegion tags in the template.
Hope this helps,
Paul
|
|
|
Powered by
FUDForum. Page generated in 0.02231 seconds
] 
Search
Help
Register
Login
Home
