As a part of the multi-tier Cayenne coding (which is shaping up
pretty nice BTW), I've done some work integrating client class
generation into the new cgen task. Here is a few thoughts on how to
shift things around in cgen. Mike is probably busy with other things
now, but let's keep this for the record until Mike, myself or someone
else has a chance to resume work on class generator changes.
I really love all new additions - tools, VPP, entity filtering, new
templates. However I think we can arrange things much better.
Problems:
* Generator code is generally pretty dirty. This problem predates
recent changes, it is just that when we started extending the
original version, things got much worse (version 1.1, version 1.2!)
* Generator is way overloaded with options (and I added one more -
"client"). The number of combinations is growing, so it becomes much
harder to use (not to mention - maintain). What I always liked about
Ant is that it took seconds (ok, maybe minutes) to figure out how to
use most of the core tasks. We should adhere to the same principle.
* I think we are mixing two things together, confusing the users and
making our life harder:
(1) A generic mechanism for building a file by combining a
Velocity template with DataMap or Entity metadata;
(2) Cayenne DataObjects generation mechanism which something
similar to #1, but with one important distinction - it has internal
logic to mix and match one or more templates. And this logic is
specific to Cayenne.
Suggested design/refactoring:
Split new cgen in two or more tasks (not cgen and cgen2 as I
suggested earlier ... that was really dumb).
Task 1: "cgen" - it will continue doing what it is doing now. We can
easily switch to Mike's tools and new templates seamlessly (without
version check)! Just stick the old ClassGenerator in Velocontext
together with the new tools and bingo - both 1.1 and 1.2 templates
can be processed. Another big problem - VPP dependency ... cgen won't
have it anymore. We simply won't allow custom tools in it. Period. If
your custom template requires VPP, use one of the tasks below (I
guess we may deprecate "template" and "supertemplate" overrides at
some point). Instead of "mode" flag we may just add flags that have
meaning for Cayenne stuff generation. E.g. "queries" to generate a
queries file.
.. Tasks below will be used for custom single template processing
with VPP support ... I suggest to split two current modes into two
separate tasks for clarity (e.g. "includeEntities" probably makes no
sense for DataMap mode). But I haven't fully made up my mind on that.
Also the names are just placeholders. Better suggestions are welcomed.
Task 2: "ctemplate-entity" - custom template processing with VPP in
"entity" mode
Task 3. "ctemplate-datamap" - custom template processing with VPP in
"datamap" mode
All these tasks can have a common superclass (the one that processes
common attributes: map, destDir, encoding).
Here is a summary of benefits that we'll get from this design:
* No need to have "version"
* No need to have "mode"
* Zero backwards compatibility issues
* No need to import VPP
Any comments?
Andrus
This archive was generated by hypermail 2.0.0 : Mon Jun 06 2005 - 23:10:49 EDT