ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Lenz <>
Subject Re: XMLFragment
Date Thu, 27 Nov 2003 12:41:13 GMT
Hi Stefan,

sounds cool. Some comments inline:

Stefan Bodewig wrote:
> Hi,
> I've just added a utility class to CVS HEAD that can be used to turn
> nested content into a DOMFragment (not necessarily a tree).  I.e., if
> you use it as your nested element like
>     public void addContext(XMLFragment f)
> you can get the DOMFragment corresponding to the structure nested into
> <content> from
>    <content>
>      <some-element>with nested text</some-element>
>      <and-another-one with="parameters"/>
>    </content>

With automatic typo correction ('x' -> 'n') in the introspection code ;-)

> via f.getFragment()

which will return a org.w3c.dom.DocumentFragment object, I assume?
Any reason why the introspection doesn't look for that interface directly, 
instead of XMLFragment? I.e.:

     public void addContent(org.w3c.dom.DocumentFragment f)

> Dominique has posted similar code here and on the user list a couple
> of times and Upayavira needed something like this for his cocoon Ant
> task.  I will need it for my <nant> and <msbuild> sandbox tasks.
> Some notes:
> * it doesn't deal very well with mixed content - but this is a general
>   problem of all Ant elements.
> * Namespace support is not complete.  Peter, correct me if I'm wrong.
>   I can get the namespace URI and the local name, but I can't get
>   access to the prefix actually used on the elements when I use the
>   DynamicConfigurator interface.

Most use cases don't need the actual namespace prefix, but it would be nice 
to have for completeness.

>   Right now I don't parse the name at all, it may be better to extract
>   the namespace URI and the local name (currently commented out in the
>   committed code) instead.

So the namespace URI and the local name are currently actually passed to the 
DynamicConfigurator in the form namespace-uri:local-name? I wasn't aware of 
that. Wouldn't it make more sense to add a DynamicConfiguratorNS interface, 
possibly extending DynamicConfigurator, that would pass all the required 
information explicitly?


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message