Looks good to me.
I guess we will have to pay attention to backwards compatibility issues as
we move forward, as people use custom templates that rely on "classGen"
key... And this is a combined community of Cayenne and WOProject/WOLips
> As a first step in class generation refactoring, I'm setting up a unit
> test to verify that the test cayenne model generated classes matches
> the current generated class output.
> In the process of doing that, I'm splitting the overloaded
> ClassGenerator class into ClassGenerator (performs template generation)
> ClassGenerationInfo (stores and makes available information about class
> generation for use in templates and MapClassGenerator [class/package]).
> ClassGenerator creates and provides a reference to the
> ClassGenerationInfo object.
> All of the ClassGenerationInfo().set*() methods are marked protected as
> I don't see a valid use case for a template changing them.
> I'm also providing deprecated methods via delegation in ClassGenerator
> to ClassGenerationInfo instance variables.
> Does anyone see a problem with this split? I don't think there's any
> backwards-compatibility issues, but maybe I'm overlooking something.
> As always, my eventual goal is to replace "classGen" in the template
> with "objEntity, packageName, superPackageName, superPrefix, className,
> superClassName, formatUtils" and whatever else makes sense, as well as
> providing the ability to add in additional velocity templating tools.
This archive was generated by hypermail 2.0.0 : Tue May 10 2005 - 12:46:57 EDT