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 02:25:55 GMT
--- Jose  Alberto Fernandez <> >

> I woould have quite a few problem with ANT going
> back to a
> DOM internal representation, as oppose to the
> current SAX ->
> custom representation used today. DOM is extremely
> heavy
> and I see no reason for it just because of the GUI.

A couple of followups on this, and then I'll get into
the architectural benefits (which would be leveraged
by the GUI).

There is a difference between asking that a class, say
Project, Task, or Target, implement the
org.w3c.dom.Element interface, and the way that these
classes are built up into a tree structure. The
DocumentBuilder class (which, by the way, uses the SAX
parser) does create a large data structure which
faithfully renders (almost) every byte of data in the
original source file. And *my* goal for the GUI would
be to create such a large data structure, with
Project, Target, and Task instances (and Properties et
al.) sitting happily in the middle of this large data
structure. The GUI wants all this data (more below).

However, Ant doesn't. Therefore, it would not use the
DocumentBuilder, but the SAXParser class, whereby it
would ignore the goo it didn't need and build up the
data structure in its own optimized way. Furthermore,
the Project, Target, Tasks, etc. classes would have
nice friendly accessor methods like
Project.getTasks(), Target.getDependencies(), that
may, or may not just delegate the work to the
implemented org.w3c.dom.Node methods (an
implementation detail that's irrelevant to this design
discussion). Therefore in the Ant code you could do
something like this:

BuildFile f = new BuildFile("build.xml");
Project p = ProjectFactory.parse(f);
Target defTarget = p.getDefaultTarget();

No DOMness exposed. And assuming that ProjectFactory
is sufficiently elegant, the classes are only as
"heavy" as neccessary.

There is an argument for having no implementation of
the DOM interfaces, and requiring the GUI to delegate
from a DOM structure to the Ant datamodel, but that is
where I am right now, and I'm having to essentially
reimplement the whole data model to do that. My
argument is that if the Ant data model object
implement the Element interface, then a lot of power
can be derived from it.

> I see no reason for the GUI being able to manipulate
> ANTs
> internal representation of the build. Is there any
> good reason for
> this?

Editing is the primary reason. And in this discussion
I don't think we should think of it as an "internal
representation". That's what we have now. What we want
is an API. There are probably many other reasons
outside of editing that an external app may want to
manipulate Ant's data model (e.g. implementing

> Why not using SAX as the inter-module representation
> of the build.

As far as my understanting goes, SAX isn't a
representation, but just a way of firing events in a
serial manner when data/tokens of a certain type come
along in the XML stream.

> From ANTs point of view, the XML is read-only. If
> the GUI makes changes
> it just sends the new XML definition as a SAX stream
> and ges from there.

In the current implementation, Ant is a single
threaded, single round execution tool. A GUI wouldn't
manipulate the data representation as it was
executing. So yes, right now in the GUI when you
launch a build (at least in the last version that
would actually load a build file ;-( ), I just have
Ant reread the XML file again. However, it would be
even more efficient if I could just give it the
Project node in the DOM, and tell it to go. Because
Project, etc. would have the so called "friendly"
methods that Ant wants, it will never know that it
just got passed a data model that is "heavy" with
comments and whitespace.

> Now, what I can see is the need for a more powerful
> listener
> architecture that can tie the SAX representation in
> ANT back to the
> GUI representation. Maybe IDs is a way to achieve
> this.
> If every event where to return the ID of the object
> affected by the event
> then the GUI could locate its corresponding GUI
> model and act upon it.

I'm not sure I follow this one, so you'll have to
clarify. I'm not sure what adding IDs to each element
in the DOM would give you.


Mustard Seed Software

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

View raw message