Of course adding a standalone fileset "task" to a target containing a script task
should allow the same sorts of things to be done.
My points being that the for-each task needs to adapt to the task to be called, and
you need the full expressive power of a language
to handle all cases.
A point in XSLT's favour is that the task declarations end up looking very much like
they would outside of the for-each task.
Wouldn't it be nice to use a fileset to produce a comma separated list of filenames
needed by the current javadoc thread?
(Unfortunately, due to xslt's lack of iteration functions that particular example
would require just about the ugliest example of
xslt that a beginner could imagine.)
> -----Original Message-----
> From: Brett Knights [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, June 21, 2001 10:30 AM
> To: [EMAIL PROTECTED]
> Subject: RE: for-each (another proposal)
>
>
> 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
> >
>
>
