ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cos...@eng.sun.com
Subject Re: XML Entities (was: What flavour of scripting?)
Date Sat, 04 Mar 2000 18:04:39 GMT
> Costin wrote:
> > Hey, I said  I'm sorry - that's what happens when you try to do something
> > quickly. Feel free to -1 it and I'll rool it back  - feedback _is_
> > important, sooner the better!
> 
> Er, no.  Actually strongly +1.
> 
> And I like the suggestion to move to entities.  Can we have both?

Well, S/N problems. I said that few times in this thread. Use constants
where you need constants, use variables where you need variables ( if you 
realy need them ). 

> > For -D and "special" entities you need to tell the parser how to resolve
> > the entity. It's another hack, but at least the semantic for entities is
> > defined clearly and not so easy to turn into something else.
> 
> If I'm understanding this correctly, the logic to expand entity references
> would be in XmlMapper, not in every task, right?

Expand entity is already done in the XML parsers, not even in XmlMapper. 

I'm not sure if that will work or not - I'll write a prototype after
ApacheCon. It should be possible - SAX has  callbacks to resolveEntity,
unparsedEntityDecl and probably that's enough.

The problem is just to make "special" constants work ( like java.classpath
and all the "predefined" constants) and also to allow command line
override.

IF we can't make it work - it is still a good idea to keep constants and
variables separated, and use variables and scripting _only_ when it is
needed.


> 
> Also, how would tasks like Available work?  It seems to me that this too
> should be moved outside the scope of the document.  Perhaps it should be a
> processing instruction (XML PI)?

Possible - if resolveEntity() does the trick there is no problem, we'll be
able to add entities at runtime. I have to try first.

Costin


Mime
View raw message