On Wednesday 05 November 2003 16:26, Dominique Devienne wrote:
> > From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> >
> > On Wed, 5 Nov 2003, Matt Benson <[EMAIL PROTECTED]> wrote:
> > > In beta1, the following worked:
> > >
> > > <myns:mytask>
> > > <myns:mytype />
> > > </myns:mytask>
> > >
> > > In beta2, I get an error to the effect that "mytask"
> > > does not support nested "mytype".
There was a bug in beta1 with regard to namespace
handling of nested elements (the prefix was
incorrectly ignored).
This has been fixed in beta2.
The current behaviour is that introspection discovered
nested elements belong to the ant default namespace.
> >
> > Not yet fully decided - one of the issues that is holding up the 1.6
> > release.
> >
> > I'd say it should work exactly that way (and only work for the default
> > namespace if you've defined a local default namespace):
> >
> > <myns:mytask xmlns="uri-corresponding-to-myns">
> > <mytype />
> > </myns:mytask>
>
> Hold on! I need to understand what you just said Stefan.
>
> This means that if I declare all my namespace prefixes at the top level
> like I do now, I'd have to prefix all nested elements of my tasks with the
> NS prefix?
>
> And what about tasks that takes Ant nested element, like filesets? Do these
> need to be prefixed too?
>
> And what about an Ant task (say <dummy>) with a AddXyz(Xyz xyz) method, and
> I have an <my:xyz> in my AntLib that extends Xyz? Should I be able to say:
>
> <dummy>
> <my:xyz ... />
> </dummy>
No, the ant task needs to have a add(Xyz xyz) method for this to work ...
well there is an undocumented attribute ant-type which means that one
can do:
<dummy>
<xyz ant-type="my:xyz" .../>
</dummy>
>
> And thus get limited polymorphism?
>
> Your post opens up the door to many questions for me. --DD
There are some other issues, in ant 1.7 we hope to move
from staticly adding conditions, filters etc to using <typedef/> for
them. Using the new namespace rules would mean that this is obvious.
For example:
<antcontrib:if>
<antcontrib:or>
<antcontrib:equals arg1="a" arg2="${prop}"/>
<newcondition url="http://apache.org..."/>
</antcontrib:or>
<antcontrib:then>
<echo>succeeded!</echo>
</antcontrib:then>
</antcontrib>
of course <or/> and <equals/> will be added as typedef'ed conditions so the
following will work in 1.7 (but not 1.6 with the new rules)
<antcontrib:if>
<or>
<equals arg1="a" arg2="${prop}"/>
<newcondition url="http://apache.org..."/>
</or>
<antcontrib:then>
<echo>succeeded!</echo>
</antcontrib:then>
</antcontrib>
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
