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
users.
Andrus
> 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)
> and
> 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.
>
> -Mike
This archive was generated by hypermail 2.0.0 : Tue May 10 2005 - 12:46:57 EDT