Why write another code-generator
There already exist so many tools that can be used for code-generation-
Velocity, JET. There is also the cool DOM/AST API from eclipse. Velocity and JET are both
template based general purpose generators akin to scripting languages.
1. As your code
generation needs get more complex the templates can become complex or you end up
building a template library unless your templates are very carefully designed. Programmers are quite comfortable with using an
object oriented code generator something akin to a servlet generating
web-content. It can be handy in simplifying the coding of the logic in the
code-generator. However another problem that emerges is that of method,
constructor, initializer body content which often is best implemented using a
scripting templating system. The code-generator used by the RB plugin is object
oriented and has object representations for classes, interfaces, methods, etc.
For building method, constructor, initializer body content one can
use velocity or JET as an option where its usage adds elegance and maintainablity. The
solution is similar (but not the same) to the popular MVC approach involving
servlets and JSPs.
2. There is a stage 2 for this
java code generator (I am somewhere at the end of stage I) wherein I will be
writing a parser to parse templates written for JET (the .javajet file)
and velocity (say a .javavm file) and generate code-generators with the same
concepts as the JET java code-generator'-generator but with one vital
|The generated code-generator will
not have code like
||Instead the generated code-generator after
stage-II will have code like
|The generated code generators (from JET) have a method- public String generate(Object argument)
which contains the following
||The generated code generators will have a
method- public String generate(Object argument) which will contain the
someMethod = new Method("get" expr + "Msg",
false, false, true, true, false, clazz,
comment);someMethod.addParameter(new NameType("locale", "java.util.Locale"));
new Content(someMethod, ContentLocator.get("someKey", arg1);
||There will also be generated a single property
xml file associated with the code generator to hold content like the
method content inside CDATA sections. Method objectss will fetch their
content from this using someKeys the above code passes.
||Otherwise for obtaining the method contents the
generated code could also conatin helper methods- methods other than
"public String generate(Object argument)" generated in the
code-generator with appropriate method parameters for the helper methods.
These helper methods could be edited by even editing the properties xml.
Existing (as of now in stage I) Benefits of using this codegenerator:
- It takes
care of computing the import statements automatically.
- In the generated rb plugin there is no restriction on what should be the
parameter names etc of the generated code because if there is any chance of
collision the generated code is self adjusting and ensures ther is no name
- It is simpler to use than DOM/AST API as unlike DOM/AST API it is limited in purpose. A user
of the code generator has only to deal with the package com.raghuraman.codegen
containing classes like- OuterClass,
OuterInterface, Field, Method, Constructor, Initializer, NameType, Content,
NestedClass, NestedInterface, GeneralAccessLevels, CodeFormatter. All the public api is only in the package com.raghurman.codegen. Users need not be concerned with other packages and
Actually I should not
call it a code generator but rather code-generator-model classes.
As of now the RBPlugin is using this codegenerator for the sake of
convenience. This is not a rigid stand. I can replace my code-generator with a
conventional ".javajet" or velocity based template if needed.
Copyright © 2004 R.Raghuraman. Distributable under LGPL license.