>> yea, i thought about this as well...(subclassing the generated
>> classes)...and i'm thinking that is probably the only decent solution, but
>> it does complicate things a bit...i'm still not 100% fond of
>> generating java
>> code like that...
>
>It sounds like subclassing generated classes is the only "workable" solution
>at this point and probably isn't the best for this particular situation.
>
Code generation is a particular interest to me.
I am working on some tools which take an abstract object definition
and generate the (database-specific) DDL, the BaseObject-derived classes,
and the BasePeer-derived classes.
Rather than doing subclassing for customization, I was going to use
comment-tagging
of generated methods (i.e. a comment of a certain format identifies a block of
code as having been generated and therefore replaceable by the generator.).
Many code generating products work this way.
(I will admit that most of them use so many comments that they make your code
look like crud. My tools would not do that.)
So I'm not sure why the "subclassing is the only workable solution".
The tools would also patch the database instance and unload/reload/modify
data in
the existing table. The whole goal of this is to be able to type "make"
and the
database gets modified from sources as easily as the code does (and they are
always in sync). ;-)
The tools will be prototyped first in Perl (at which I am an expert, I am
learning Java) driven by config files full of meta-data.
Maybe one day this will turn into Java code set, driven by XML
(which seems to be all the rage among Java developers).
However, in the near-term, I can certainly contribute my knowledge about how
to generate DDL for a reasonable set of databases.
Stephen
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
