Leon,
I have been using code generation for many years now in projects/products. I
have generated every file type imaginable from java files, including all java
patterns, factories, value objects, etc, to jsps, to xml config, wsdl and xsds,
to stored procedures, and database sql, to entire frameworks, and generally
this happens with the push of a button.
I appreciate your comments. However, if you have not successfully used code gen
i might suggest you take a second look.
Think wsdl to java. On the server side you generate a set of boilerplate
implementation classes which include a set of stubs for the web service
interfaces. The developer then codes in the implementation for each method.
Quite often changes are made to the wsdl and the files need to be regenerated.
In this case it would be nice to maintain the existing developers code.
If it helps perhaps i messed up my example:
Perhaps a better one
package ${packageName};
public class FooFactory {
private Properties props = PropertyLoader.load("${packageName}/config.xml");
public Object create() throws Exception {
Foo foo = new Foo();
foo.configure(props);
return foo;
}
}
package ${packageName};
public class Foo implements Configurable, BusinessAPI {
public void configure(Properties props) {
...
}
public void doSomething() {...}
}
config.xml
foo.propertyA = x
foo.propertyB = y
Here we generate a Factory, a BusinessAPI, and a config file
Anyway code generators are capable of generating a large number of files, 100s
or 1000s, and in any format: java, xml, wsdl, c#, etc. Code generation is a
tool and should be used in conjunction with other best practice techniques from
good design to externalizing properties etc. There are pros and cons to code
generation which depend in large part on how you are using it and what you are
using it for. The critical thing of course is that you are doing things
correctly.
> Date: Mon, 20 Jul 2009 14:38:11 +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
>
> 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
>
_________________________________________________________________
Windows Live™ Hotmail®: Search, add, and share the web’s latest sports videos.
Check it out.
http://www.windowslive.com/Online/Hotmail/Campaign/QuickAdd?ocid=TXT_TAGLM_WL_QA_HM_sports_videos_072009&cat=sports
