(rather than go through your points one by one - interesting as they
are - i'm going to start at the beginning...)
On Saturday, June 23, 2001, at 06:47 AM, Jason van Zyl wrote:
> What exactly are you trying to do? I don't really see why any of
> these things would be required given what you can place into the
> context via properties files. But as I'm not familiar with the task
> you're using texen for I probably don't fully understand. I'd like
> to try and keep texen as simple as possible.
(i guess i should remind you all what i'm talking about)
a while ago i talked to gier (on this list) and jon about using texen to
speed up the creation of ecs2 (over at the jakarta-ecs project)
basically the idea was to read in xml schema (created from DTDs) and use
the information to generate source code. generating source from xml -
and in particular schemas - is pretty useful in general so i didn't want
to make an ecs-only solution. (also the generation stuff doesn't fit
very well with the ecs stuff.)
the plan (as far as i understood it - maybe somebody might like to jump
in here) was for me to go ahead and develop the stuff i needed and then
feed anything which might be generally useful back into the velocity
loop.
so here goes...
i started by looking at torque and thinking about producing a new
subclass that places an object model parsed from a schema into the
context. there are a number of reasons why - if possible - i didn't
want to use this approach (in this case). one big reason was that i
wanted to have the flexibility to be able to generate more sophisticated
versions of the object model without having to change the subclass - or
even change to using a general object model such as JDom or a DOM walker
later.
as far as i can see (maybe somebody would like to correct me), the
fundamental way that all the velocity generation tasks work is by
placing certain objects into context(s) and then running velocity. i'd
agree that most of this stuff could certainly be achieved by extending
how the properties file works instead - it's just that IMHO it's not as
natural or powerful to achieve the effect in this way. nested elements
allow the use of reflection to set properties on the beans before they
are placed into the context. nested elements can also take advantage of
ant's general infrastructure. of course, you could do most of this in
the script - but another aim was to keep the scripts simple and readable.
- robert
