ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jose Alberto Fernandez <>
Subject RE: Proposed Revolution: AntEater (a proposal for Ant Core 2.0)
Date Tue, 14 Nov 2000 05:02:32 GMT
> From: Simeon Fitch []
> 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
> parallelism).

This is exactly what I think is very very wrong. Lets assume
that you have the ability of editing ANTs internal representation
of the project. Now that means that any validation or caching
that ANT mades to its representation of the project it may be
put at risk of inconsistencies because the GUI decided to edit
something,for example, in the middle of a run (in some other thread).
This would mean a lot of defensive coding just to protect against
extrange manipulation of the internal representation.

BTW, one of my problem with the current API exposed by <script>
is that is allows people to do things like this. I think that is wrong.

> > 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.

My point here is the following:
(1) The GUI has its own (DOM) representation of the build file.
(2) When the user pushes the button for an execution, the 
    following code happens:

	DOM dom = gui.getDom();
	ProjectContentHandler pch = ProjectFactory.getContentHandler();
	Project p = pch.getProject();

I am not using real API names, is just a code sketch. The point is that
from your DOM we get an instance of the project use it and discard it
once we have use it. The only permanent representation is the GUIs.
ANT's representation only lives as long as ANTs execution.

This is not all is needed, you probably will need a way to catch
requests from ANT to execute other projects that it trys to build
using <callant> and <ant>. So there should be an API for ANT to ask
for it, that the gui can intercept and look at its onw repository of
DOM in memory subprojects. So that they are retrieved from the GUIs
DOM representation.

But all that can be done without manipulating ANTs internal representation.

> > 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.

This is exactly what the code above does, the difference is that
your datastructures and ANTs are separate. If you decide to make big
changes or ANTs does, as long as the XML and ANTs semantics
remains the same no one is affected by the other changes.

> > 
> > 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.

If the datastructures are different, we still need a way
for the GUI to find out what is going on during the execution
of the build, like for doing tracing of the execution.

So you want the GUI to be able to listen for events and being able
to associate identify which object in its DOM representation should
be affected by the event produced by ANT. I am not sure that the
current Listener API is informative enough.

The idea I was thinking was to decorate the DOM with IDs which are
stored in a table or something, and have the Listener events return
those IDs as part of the even stream. With this the GUI will be able to
correlate the two representations.

Hope this is more understandable.

Jose Alberto

View raw message