|
| Re: JMerge experiences [message #46601 is a reply to message #46548] |
Thu, 29 May 2008 17:12   |
 Paul Elder
Messages: 849
Registered: July 2009 |
Senior Member |
|
|
Timothy:
JET2 has a <java:merge/> tag. Just put it in your Java templates (after any
<java:importsLocation/> tags, there is an undesirable interaction
otherwise).
The <java:merge/> tag does is the following:
1) During template execution, it does nothing at all (except set a flag
indicating that a JMerge is required).
2) As the JET engine finalizes the generated output, the tag kicks in and
checks for an existing version of the class. If found, a JMerge is run and
the result is written. If there is no existing class is found, then the
original buffer contents are written.
As for an opinion on JMerge, I have two views:
1) I like it - it has a simple usage contract that users can understand.
2) Your transformation will be better if you can avoid merges entirely. In
many cases (at least with Java code), you can do this by refactoring your
generated code into two kinds of classes: i) those that are 100% generated;
and ii) those that are 100% under user control. As a convenience to the
user, the transformation may create files in ii), but it would never modify
them. Physically separating the two kinds of files into different folders
makes this even easier for the user.
Paul
|
|
|
| Re: JMerge experiences [message #46739 is a reply to message #46601] |
Sun, 01 June 2008 10:03 |
Timothy Marc
Messages: 547
Registered: July 2009 |
Senior Member |
|
|
Dear Paul,
thank you, i've know get use of JMErge with JET1. It works fantastic.
Timothy
Paul Elder schrieb:
> Timothy:
>
> JET2 has a <java:merge/> tag. Just put it in your Java templates (after any
> <java:importsLocation/> tags, there is an undesirable interaction
> otherwise).
>
> The <java:merge/> tag does is the following:
> 1) During template execution, it does nothing at all (except set a flag
> indicating that a JMerge is required).
> 2) As the JET engine finalizes the generated output, the tag kicks in and
> checks for an existing version of the class. If found, a JMerge is run and
> the result is written. If there is no existing class is found, then the
> original buffer contents are written.
>
> As for an opinion on JMerge, I have two views:
> 1) I like it - it has a simple usage contract that users can understand.
> 2) Your transformation will be better if you can avoid merges entirely. In
> many cases (at least with Java code), you can do this by refactoring your
> generated code into two kinds of classes: i) those that are 100% generated;
> and ii) those that are 100% under user control. As a convenience to the
> user, the transformation may create files in ii), but it would never modify
> them. Physically separating the two kinds of files into different folders
> makes this even easier for the user.
>
> Paul
>
>
|
|
|
| Re: JMerge experiences [message #46758 is a reply to message #46601] |
Sun, 01 June 2008 10:27 |
Timothy Marc
Messages: 547
Registered: July 2009 |
Senior Member |
|
|
Hi,
it's me again.
Just a question concerning the documentation of JMerge. I've searched in
the web and the help files, but there is no document, which describes
the available elements in a rule and their attributes.
Is there somewhere outthere an API nly for the configuration of the rules?
Timothy
Paul Elder schrieb:
> Timothy:
>
> JET2 has a <java:merge/> tag. Just put it in your Java templates (after any
> <java:importsLocation/> tags, there is an undesirable interaction
> otherwise).
>
> The <java:merge/> tag does is the following:
> 1) During template execution, it does nothing at all (except set a flag
> indicating that a JMerge is required).
> 2) As the JET engine finalizes the generated output, the tag kicks in and
> checks for an existing version of the class. If found, a JMerge is run and
> the result is written. If there is no existing class is found, then the
> original buffer contents are written.
>
> As for an opinion on JMerge, I have two views:
> 1) I like it - it has a simple usage contract that users can understand.
> 2) Your transformation will be better if you can avoid merges entirely. In
> many cases (at least with Java code), you can do this by refactoring your
> generated code into two kinds of classes: i) those that are 100% generated;
> and ii) those that are 100% under user control. As a convenience to the
> user, the transformation may create files in ii), but it would never modify
> them. Physically separating the two kinds of files into different folders
> makes this even easier for the user.
>
> Paul
>
>
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.05345 seconds
] 
Search
Help
Register
Login
Home
