ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <cmanola...@yahoo.com>
Subject RE: Project.toXML() ?
Date Mon, 14 Oct 2002 16:53:28 GMT
Dominique Devienne wrote:

> I'm amazed how a DOM-based ProjectHelper always gets dismissed when it's
> clearly the ideal solution to provide serialization back to XML from the
> original XML (among other things):

Ant1.5 supports pluggable ProjectHelpers, and nothing stops you from 
creating a DOM-based one.

I'm not sure that 'serialization back to XML' is a very common use
case - but if you write a DOM-based helper and it is comparable in 
speed with the current one, I'm ready to vote +1.

My interest is more on using ant without an XML file - using APIs.   
Using DOM is probably ok ( UE/RuntimeConfigurable are a bit more neutral ).

> 1) It keeps all the info needed,

Same can be done with UE/RC.

> 2) It's standard and well documented, whereas UnknownElement /
> RuntimeConfigurable, which emulates it basically (with added stuff
> granted), is not,

I agree with this point. 

> 3) It allows total separation of the parsing from the instantiation of the
> model,

That's already done. The helper is completely independent from the 
rest - and so far I've seen no problem. 

It would be a problem if a particular DOM processor would become required - 
as it'll actually reduce the separation. 

> 4) It would speed up <antcall> but not having to re-parse, and save memory
> too by keeping around the DOM tree (if <antcall> element are detected for
> example),

Same can be done with UE/RC. 

> 5) It would allow programmatic XSL hooks to would feed the transformed
> document (in memory DOM tree) directly to Ant. This feature alone would be
> fantastic!!!

However that may lead to unmaintainable build files and a lot of complexity.
The object tree can be manipulated even now, and as I said it is perfectly 
possible to use a DOM+XSLT+whatever helper. 
 
> 6) It would allow a clean, at parse-time import/include model, similar to
> XSL.

The include/import model works fine right now. I prefer reducing as much as 
possible the parse-time logic and functionality ( and thus the dependency on
XML files ). 

> Finally, I'd say it that it would also allow something I've wished for for
> some time now... The ability to externally change a build file attribute
> *without* requiring to go thru a property. Something like:
> 
> ant -D//javac/@debug=true build

While I don't like too much this particular use case ( it would make ant 
too complex IMO ), I think it could be implemented with a bit of jxpath
and some extensions to the dynamic properties.


Overall I don't see any problem with DOM as long as it doesn't affect
the separations between parser/runtime. I don't thing the benefits would
be that great either - but I'm not oposed to the idea.

--
Costin



--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message