commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Weinstein <jasonweinst...@hotmail.com>
Subject RE: New Tag - Looking for Comments (Maintain user code during regeneration of files)
Date Mon, 20 Jul 2009 19:09:03 GMT


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.leon@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<jasonweinstein@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.leon@googlemail.com
> >> To: user@commons.apache.org
> >>
> >> On Fri, Jul 17, 2009 at 11:11 AM, Jason
> >> Weinstein<jasonweinstein@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-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: user-help@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@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
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message