Hello Jason,
thank you very much for the detailed answer.
On Mon, Jul 20, 2009 at 12:42 AM, Jason
Weinstein<jasonweinst...@hotmail.com> wrote:
>
> Hi Leon,
>
> Often generated files are only a starting point.
An interesting point. Actually the mess that happens if you try to
"regenerate" edited generated file is the main agrument against code
generation (see also rod johnsons j2ee development without ejb). So
why would someone use a system that actually relies on changing
generated code?
Giving 2 examples: How many real life projects REALLY use code
generated by rational rose et al?
But, millions of sites are using jsps on the daily basis, as an
example of code generator jsp -> jsp.java and i think that noone
actually edits and changes code generated by jasper or other jsp
generator / compiler.
So maybe instead of allowing user to alter generated code and even
persist those changes over generation cycles, it makes more sense to
parametrize either the generator or the generated code, so there is no
need to edit it? Staying with your it would be :
public class Factory {
private String className = RuntimeConfiguration.get("className");
public Object create() throws Exception {
return Class.forName(className).newInstance();
}
This way you at least can rely that the result of a generation is
predictable and repeatable for the defined version of the generator.
regards
Leon
>
> Example
>
> Template
>
> public class Factory {
>
> private String className = "${className}";
>
>
>
> public Object create() throws Exception {
>
> return Class.forName(className).newInstance();
>
> }
>
> }
>
>
> First time template generates:
>
> public class Factory {
> private String className = "foo";
>
> public Object create() throws Exception {
> return Class.forName(className).newInstance();
> }
> }
>
> User may change this generated file to be:
>
> public class Factory {
>
> private String className = "foo";
>
>
>
> public Object create() throws Exception {
> Object o = Class.forName(className).newInstance();
>
> System.out.println("creating object " + o);
> Statistic.createdObject(className, +1);
> return o;
>
> }
>
> }
>
> Template may be updated to generate:
>
> public class Factory {
>
> private String className = "foo";
>
>
>
> public Object create() throws Exception {
>
>
> return Class.forName(className).newInstance();
>
>
> }
>
>
>
> public Object create(ClassLoader cl) throws Exception {
>
>
> return Class.forName(className, cl, true).newInstance();
>
>
> }
>
>
> }
>
> When user code is maintained the generated file would be
>
> public class Factory {
>
> private String className = "foo";
>
>
>
> public Object create() throws Exception {
> Object o = Class.forName(className).newInstance();
>
>
> System.out.println("creating object " + o);
>
> Statistic.createdObject(className, +1);
>
> return o;
>
>
> }
>
>
>
> public Object create(ClassLoader cl) throws Exception {
>
>
>
> return Class.forName(className, cl, true).newInstance();
>
>
>
> }
>
>
>
> }
>
> And not (missing user code)
>
> public class Factory {
>
>
> private String className = "foo";
>
>
>
>
>
> public Object create() throws Exception {
>
>
>
> return Class.forName(className).newInstance();
>
>
>
> }
>
>
>
>
>
> public Object create(ClassLoader cl) throws Exception {
>
>
>
> return Class.forName(className, cl, true).newInstance();
>
>
>
> }
>
>
>
> }
>
>
> Many times generated files need updating. Sometimes generated files are just
> starting points meant for the user to fill in and sometimes they are meant to
> be final results but developers/users may wish to make mods to them anyways.
>
> The above is a simplistic example, but a user mod could be anything from
> adding an annotation to a log statement to employing an optimization such as
> a cache to adding a new method, etc.
>
> What i presented, was a simple practical way to allow user mods to be
> maintained during file regeneration.
>
> In conclusion, very often not everything is accounted for during generation.
> Sometimes the files need to be regenerated as templates change. What was
> presented was a way to maintain user changes in the generated files as files
> are regenerated. When combined with a compile step this also allows an easy
> way to flag incompatible user changes, or simply flag that the file was
> changed by the user.
>
>
> These types of comments often need work arounds in real systems as generated
> code does not always meet user requirements or may even have bugs or other
> limitations.
>
> // user generated code - do not modify - overwrites
>
>
>
>
>
>
>
> A couple side thoughts
>
> <use as template> - way to use different template during codegen, useful as
> workaround for end user in prod system
> <crc file> - way to test for user mods, and flag errors, may skip whitespace,
> etc
>
>> Date: Sun, 19 Jul 2009 14:04:53 +0200
>> Subject: Re: New Tag - Looking for Comments (Maintain user code during
>> regeneration of files)
>> From: rosenberg.l...@googlemail.com
>> To: user@commons.apache.org
>>
>> On Fri, Jul 17, 2009 at 11:11 AM, Jason
>> Weinstein<jasonweinst...@hotmail.com> wrote:
>> >
>> > A common problem with templating systems is that they overwrite changes
>> > made
>> > to the generated files, when things are regenerated.
>>
>> Hello,
>>
>> maybe I don't understand your point, but why should someone change
>> generated files?
>>
>> Leon
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
>> For additional commands, e-mail: user-h...@commons.apache.org
>>
>
> _________________________________________________________________
> Windows Live™ Hotmail®: Celebrate the moment with your favorite sports pics.
> Check it out.
> http://www.windowslive.com/Online/Hotmail/Campaign/QuickAdd?ocid=TXT_TAGLM_WL_QA_HM_sports_photos_072009&cat=sports
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
