ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simeon Fitch <>
Subject Re: Proposed Revolution: AntEater (a proposal for Ant Core 2.0)
Date Tue, 14 Nov 2000 14:41:40 GMT

--- Peter Donald <> wrote:
> At 06:20  14/11/00 -0800, you wrote:
> >> > Is your concern with keeping comments and such
> >> > inline with the tasks/targets
> >> > they represent?
> >> 
> >> Yep. And the ability to traverse a homogeneous
> >> structure.
> >> 
> >
> >Duncan, there is another partial reason for
> supporting
> >DOM semantics that was only implied here, and that
> is
> >the GUI will obviously have to write back out the
> >code that has been edited (marshal the data
> >structure). The Sun JAXP api has the concept of an
> >XMLWriteContext, which allows you to take the DOM
> >structure and output it as an XML stream. I'm
> hoping
> >to get this functionality for free. ;-) If the Ant
> >data structure doesn' fit in with the XML DOM, then
> >I'll have to traverse the DOM to preserve comments
> and
> >whitespace, and separately traverse the Ant data
> >structures with a custom XMLOutputStream (or the
> like)
> >to save it's state.
> While it may be easier to do writeout if given this
> I don't think allowing
> this is the "right way" to do things. It may be a
> bit of a PITA for you to
> rewrite the reading code but I think that is a small
> price to pay for
> cleaner core ;)

Only one of several arguments I'm trying to make, and
I don't think the "cleaner core" argument has been
strongly posed. I certainly can be swayed by this
argument (even at the expense of having to write a lot
more code), but I'd like to hear how having Project,
Task, Target, etc. implement the Element interface
results in an ugly or burdensome API (especially if
they implement it via inheritence from a AntBaseNode
class or something similar).

I hope I'm not coming across as being rabid on this
issue; I just want to make sure that the benefits are
understood from a long term perspective. That being
said, if the Ant data model ends up /not/ being DOM
compliant, I will probably have to mirror the data
model in order to preserve the ability to marshal and
unmarshal (if you will) the build.xml file in a way
that preserves comments and Text nodes. But then
again, I'm open hearing how this might be done in
another elegant fashion. I just think it would be
really simple to have an AntBaseNode class that
implements the Element interface, from which the
Project, Target, etc. classes inherit, to take care of
all this. The users of these Ant classes needn't even
know about all the DOM related methods if they don't
want to. Those who do can just refer to the
AntBaseNode class.



Do You Yahoo!?
Yahoo! Calendar - Get organized for the holidays!

View raw message