> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> On Fri, 4 Jun 2004, Matt Benson <[EMAIL PROTECTED]> wrote:
> > If there is any reason why we couldn't/shouldn't have
> > a generic <task> DynamicConfigurator that could
> > execute an arbitrary task by classname, and a generic
> > <type> or <object>, probably also a
> > DynamicConfigurator, to instantiate (and optionally
> > configure) an arbitrary object, usu. to set as a
> > reference, but possibly for other things as well...
>
> Ahh!!
>
> No, I don't see any reason why we shouldn't have a task/type like
> this.
This actually ties back to what Magesh proposed (the dispatch task).
One of the useful bit his proposal allowed was to conditionally
execute one mode or the other thanks to mode="${mode}", where
mode can be configured/computed before-hand. If we had a way to
configure and execute a task in a similar indirect way, we'd achieve
the same goal, will still using different tasks. Here's what I mean:
You have tasks A and B which are interchangeable, i.e. take the
same attributes and nested elements, but do different things.
Instead of doing:
if some-condition
do-A
else
do-B
or doing Magesh's
<condition property="mode" value="A">
some-condition
</condition>
<property name="mode" value="A">
<A-orB mode="${mode}" [attributes]>
[elements]
</A-orB>
We'd do something like:
<condition property="mode" value="A">
some-condition
</condition>
<property name="mode" value="A">
<task taskname="${mode}" [attributes]>
[elements]
</task>
This allows the necessary indirection, and avoids having to
Duplicate all the attributes and elements in an <if>.
This is similar to XSL's <xsl:element>, where the great majority
of time you just output the element directly, as in <a>, but
sometime need to dynamically set the elements name, thanks to
<xsl:element>.
Anyways, I hope this makes sense. --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
