That's true to a degree and is my main concern about it.
However just as with xslt's simplified stylesheet format the amount you NEED to learn
could be quite small.
My original example, stripped of comments and options, should illustrate this:
<taskTransformer>
<elements row-elem-name="file">
<fileSet .../>
</elements>
<taskStyle>
<xsl:for-each select="file">
<touch file="{.}"/>
</xsl:for-each>
</taskStyle>
</taskTransformer>
By defaulting some more of the attributes you could even get away with the following
quite comfortably:
<taskTransformer>
<files>
<fileSet .../>
</files>
<taskStyle>
<for-each>
<touch file="{.}"/> <!-- this {.} becomes the only "foreign" syntax required -->
<for-each>
</taskStyle>
</taskTransformer>
My main reason for proposing something like this is that you need to be able to
manipulate the arguments to tasks based on what they
need. For instance I went to use the execOn task (IIRC) to call an external procedure
once for each of a group of files. I needed to
pass an argument as -i{filename} but there was really no way to do that. While I could
have patched that task for my particular need
(and in this case I ended up patching another task) I don't think we want to have to
patch tasks whenever they don't do quite what
we want. There are likely many external tools that take a particular set of arguments
that we can't anticipate at present.
> -----Original Message-----
> From: Larry V. Streepy, Jr. [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, June 21, 2001 9:47 AM
> To: [EMAIL PROTECTED]
> Subject: Re: for-each (another proposal)
>
>
> I'm opposed to this for one main reason: it forces me to
> study and learn
> XSLT just do to something trivial like "foreach".
>
> Brett Knights wrote:
> >
> > Consider this:
> >
> > <taskTransformer> <!-- as it's not just a for-each (name
> suggestions gratefully accepted)-->
> >
> > <elements row-elem-name="file"> <!-- this will become the
> xml source that will be passed to the stylesheet -->
> > <fileSet .../>
> > </elements>
> >
> > <taskStyle>
> > <!-- everything in here is treated as a template that
> would normally be defined as <xsl:template match="/" -->
> > <xsl:for-each select="file">
> > <touch file="{ant:full-path(.)}"/> <!-- anticipating
> some ant specific extensions. The example could use file="." -->
> > </xsl:for-each>
> > </taskStyle>
> >
> > <templates>
> > ... <!-- optional section if further templates are required -->
> > </templates>
> >
> > </taskTransformer>
> >
> > It's not a great deal different than each of us writing a
> scripted task when we want to run over a set of files except:
> > - we can still use fileSets rather than relying on our
> scripting language's file system access routines.
> > - any task could be used in a for-each mode without modification
> > - what is produced is used as though the fully transformed
> version had appeared in the original build.xml
> > - the full power of xslt is available should it be needed.
> (and is there to bite you ...)
> >
> > The task would assemble the included elements into a
> stylesheet that would import a standard stylesheet (therefore any xsl:
> > directives in the build.xml would override the standards).
> >
> > One nice thing about the xslt route is that xslt is already
> fully documented. :-)
> >
> > There is enough work here that I won't just code it up,
> submit it, and see if it makes it. If this seems viable to
> others and has a
> > chance of making it into official Ant I'll take on
> developing it though. (At which time I guess further
> discussions would go on the
> > Ant-Developer's list)
> >
> > ***********************************************************
> > Brett Knights 250-338-3509 work
> > [EMAIL PROTECTED] 250-334-8309 home
> > ***********************************************************
>
> --
> Larry V. Streepy, Jr.
> Chief Technical Officer and VP of Engineering
>
> Health Language, Inc. -- "We speak the language of healthcare"
>
> 970/626-5028 (office) mailto:[EMAIL PROTECTED]
> 970/626-4425 (fax) http://www.healthlanguage.com
>
