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:38:19 EDT