I'm in the process of writing some improvements to the class generation
process.
I thought I'd run them by here as I'd like to submit them as a patch when
I'm done.
I find the prop methodology quite confusing and limiting.
public void setProp(String prop)
public String getProp()
public String getCappedProp()
public String getPropAsConstantName()
It's unclear to me why there aren't simply
public String capitalizeString(String aString)
and
public String javaToUnderscored(String aString)
methods.
I propose adding these two methods (with the guts of both functions in
NameConverter) and depreciating the prop stuff.
I think it'd also be less confusing if the context were preloaded with two
values, "model" and "utility" rather than "classGen." Again this could be
done with a slow depreciation.
"model" would contain things like entity and package data values, whereas
"utility" would contain capitalizeString, javaToUnderscored,
formatVariableName, formatJavaType, and any other utility functions.
The package references also should be cleaned up.
Currently we have
getPackageName
getSuperPackageName
getClassName (without package)
getSuperClassName (with package)
getSuperClassName should be changed to be without the package.
Again, all of these changes can be made without breaking backward
compatibility.
I'd also like to add a parameter to the ant task to work on a single Entity
rather than generating all entities.
I think I'd also like to rework the target template set so that it's a list
of templates to generate against rather than "hardcoding" superclass and
subclass types. Right now, I'm using the task to generate a Struts java
action (intialization), a Struts java action (action), and a velocity web
template.
So rather than
makepairs="true"
supertemplate
=".../templates/VelocityInitializeEntityReportComponent.java"
template=".../templates/VelocityEntityReportComponent.html.vm"
I'd rather use something like
<fileset dir=".../templates/">
<include name="VelocityInitializeEntityReportComponent.java"/>
<include name="VelocityExecuteEntityReportComponent.java"/>
<include name="VelocityEntityReportComponent.html.vm"/>
</fileset>
I haven't thought this all out yet, and I've never written an ant task
class, so I might be going about this the wrong way. However, it seems to
me that both superclass and subclass templates can be processed without
hardcoded knowledge of their function. Maybe it'd require something more
along the lines of:
<fileset dir=".../ModelerTemplates/">
<include name="subclass.vm" package="com.xyz.cayenne.entity"
outputSuffix=".java" />
<include name="superclass.vm"
package="com.xyz.cayenne.entity.generated" outputPefix="_"
outputSuffix=".java" />
</fileset>
Actually, the outputPrefix/suffix would pretty much be necessary in most
useful cases, as would a parameter for package and destination directory.
Anyway, I thought I'd throw this out and see what bounces back :)
-Mike
This archive was generated by hypermail 2.0.0 : Wed Jan 21 2004 - 14:33:37 EST