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 03:06:38 GMT
--- Barrie Treloar <>

> What is wanted is for the xml file to be modified
> but to keep the same
> structure as the user entered (whitespace included).
> I think what you are proposing is more inline with a
> Java/XML binding,
> which I believe is an easier way to manipulate the
> XML in a java
> centric.  That is compile XML into Java classes.

Sort of (that last part isn't needed). I don't know if
you were hinting at the type of functionality the
Enhydra XMLC tool has, which allows you to feed it an
XML document (usually HTML or WML, but not
necessarily), and it generates Java source code that
builds the DOM structure. It's a nice way to
programatically manipulate HTML code. 

The part of XMLC that is cool, is that you can
register document factories with it, so that each node
of the DOM structure is actually a specific type. For
example, when you feed it HTML, your DOM node
instances are classes like HTMLBody, HTMLTable,
HTMLTableRow, etc. with all the nice methods for
manipulating the specific components of that element.
In the XMLC model you could conceivably register an
"Ant Factory" that would allow XMLC to generate Java
source code that constructs a build file with the Ant
specific data model classes! Not that it's of much use
to us, but you could do it...

What I'm doing with the GUI right now, using Sun
specific classes, is very similar. I'm registring
specific DOM node classes with the DocumentBuilder
that the parser instanctiate whenever it comes across
the appropriate tag, like <target>. I will need to
implement my own DOM generator to get away from the
Sun classes, but generation model is similar to XMLC.


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

View raw message