> From: Phil Weighill-Smith [mailto:[EMAIL PROTECTED]
>
> My vote for a "language" within if/unless elements is to use
> XPath (1 or 2). Pretty powerful and standard within the XML
> domain! You could even think of supporting path expressions
> that access the entities (targets, properties, types etc.)
> within the current Ant build file and could provide some
> supporting functions that allow tasks and/or targets (in the
> current build) to be invoked or other ant-specific operations
> to be performed.
>
No issue on allowing Xpath, in particular because we probably
are shiping implementations of it inside the parsers or xslts
and maybe one can get hold at them.
Which means is close to enough to core.
But I would like to limit it to more or less what we can do with
conditions
I do not think we are looking for some new syntax for executing ANT
tasks. :-)
> To maintain backwards compatibility, all that is needed is a
> delimiter that indicates that an XPath expression is being used. E.g.
>
> ... if="debugmode" ...
>
> for backwards compatibility or
>
> ... if="@call("available", "file", ${file}) == true()" ...
>
If we were to allow property expansion of if/unless, you could
just say something like:
... if="${Xpath: call("available", "file", ${file}) == true()}"
ans as Stefan pointed out an Xpath PropertyHelper will take care of it.
There is still the issue of what if/unless finish testing.
> to indicate that the "available" task should be called with
> the specified property set as the "file" attribute (XPath
> supports "varargs" so having name/value pairs of parameters
> to define the attributes of the invoked task is easy to
> implement). Explicit functions could be made available for
> the most common task invocations in conditions.
>
> Finally, it would even be possible to drop the delimiter and
> evaluate the expression as an XPath instead of as a property
> name if there are any "illegal" property name characters
> (such as "(", "/" or whitespace) in the expression.
>
Illegal characters? We have been so liberal I do not thing there
are more illegal things :-)
But seriously, I do not like these shortcuts, because they will hit
us tomorrow when we try to add something and NOOOOOOO you cannot do that
because Xpath kicks in on that syntax.
BTW, something I forgot from my original set of arguments:
- Today if/unless are defined as regular attributes of tasks/targets
which means those task/targets are the ones that deal with it.
- Instead, you could think of them as meta-attributes available on ANY
element
and which is evaluated by ProjectHelper itself. Or something like that.
That would mean, that you could write not only conditional tasks, but
also
conditional subelements of tasks, everywhere. Today very few tasks
support such thing
the exception being <fileset> <exclude name="..." if="..."/> </fileset>.
So, that is another alternative which may give a lot of power. Maybe too
much?
<sequential ant:when="...">
...
</sequential>
Hey this is a conditional if!!! :-) but no way to write else :-(
Notice that <sequential/> will not be modified at all, because
eveluation occurs
before the task is called.
Of course, here we would be free of BC issues, so we could have a freer
hand
on how would it work.
Jose Alberto
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
