On Tue, 23 Jul 2002, Dominique Devienne wrote: > Just because of the way Ant 1.x mingles parsing and executing.... Would > there be a full XML parsing, getting to the DOM or a DOM-like structure
Ant is actually getting to a DOM-like structure ( RuntimeConfigurable, UnknownElement ). This has nothing to do with how the file is parsed, or even if there is an XML file at all - jasper for example is using ant without any xml. > then it would be easy to inject a DOM DocumentFragment anywhere in the DOM > tree of the main build file. You can even partially evaluate the properties > defined before the <include> just so they can be used in the <include>. You > can even properly implement an <import>, by replacing an element with > another. It is not 'easier' or 'harder'. It all depends on the semantics of the build.xml ( or whatever object tree ). Assuming you have the object model, what's the correct order of execution? Do you evaluate import _before_ properties ? What about other initialization tasks ( like a possible xmlProperties ) ? > The current sax based approach (sax1 or sax2!) is just not flexible enough > IMHO. And going with the DOM opens the door to templating by using XSLT. I SAX has nothing to do with it - and you can very well use XSLT with SAX. It's just a bit faster ( you can ask cocoon people about that ). But in the end the SAX/DOM/whatever shouldn't even be visible to applications - what is important is the definition/specification of the evaluation order. The ProjectHelper is extremely similar with the Axis processor, and also similar with Digester and XmlMapper. I'm currently making few changes to make all handlers stateless ( i.e. even closer to digester/xmlmapper - while keeping the axis elements ). I can agree that speed is not the essential factor ( or at least not as important as for axis or digester ). Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
