Hi Christopher,
This is basicly the way I have implemented my proposed
change.
However there is one problem. At the moment we are
encouraging people to use typedef's to implement
conditions, filters etc however for 1.6, the std conditions
etc are not implemented in this way. For 1.7 we hope
to implement them using typedefs (as well as fixed for
Backward compatibly issues) and implement new conditions/etc
by typedefs and not by extending ConditionBase/etc
This plumbing would be now visible in build scripts:
<antcontrib:if>
<antcontrib:or>
<antcontrib:equals arg1="a" arg2="${file}"/>
<ant:newcondition a="test"/>
</antcontrib:or>
<antcontrib:then>
<ant:echo>Hello world</ant:echo>
<antcontrib:then>
</antcontrib:if>
Peter
On Wednesday 29 October 2003 14:26, Christopher Lenz wrote:
> Christopher Lenz wrote:
> > In an earlier thread I proposed the general rule that if a namespace'd
> > task or type defines the names of introspection-discovered elements,
> > those elements inherits the namespace from its parent.
> >
> > Consider this pseudo task class:
> >
> > MyTask {
> > addFoo(Bar foo);
> > }
> >
> > This task obviously defines the name of the nested element, so the
> > namespace is inherited. Now if MyTask is in the namespace "my", we'd
> > need to write:
> >
> > <my:task>
> > <my:foo/>
> > </my>
> >
> > The same would apply if the nested "foo" element was not
> > introspection-discovered, but rather created via DynamicConfigurator,
> > because the task or type implicitly defines the name of the nested
> > element in that case. It may have a if (name.equals("foo")) in the code,
> > for example.
> >
> > Now, if the task class looked like:
> >
> > MyTask {
> > add(Bar bar);
> > }
> >
> > ...and Bar would be type defined with the name "foo", also in the "my"
> > namespace, we'd still write:
> >
> > <my:task>
> > <my:foo/>
> > </my>
> >
> > In this case the name of the nested element is not defined by MyTask, it
> > is defined when "foo" is typedef'd. However, it is defined with the same
> > namespace URI as MyTask, so while the prefix is not inherited it is the
> > same as that of its parent element.
> >
> > Now *if* the "foo" type was defined in the default Ant namespace, we'd
> > have:
> >
> > <my:task>
> > <foo/>
> > </my>
> >
> > Because MyTask does not define the name of the nested element, and "foo"
> > was not defined with the default namespace URI.
>
> Oops, I wanted to say:
> > Because MyTask does not define the name of the nested element, and "foo"
> > was defined with the default namespace URI.
>
> (note the missing second "not")
>
> -chris
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
