XPath is a language that handles complex expressions that *can* include
document navigation and "query" paths but also contains a lot of other
capabilities (consider what you can do with expressions in XSLT: these
expressions use XPath with extension functions).
My suggestion is to have Ant register extension functions with the
*XPath* context so that they are callable from XPath; however, in my
original message I suggested a single (standardized) "call" method that
can be used to call any registered Ant task as a catch-all. I also
suggested that you *might* want to invoke a target (for some reason)
within the expression and that this could be achieved using the document
navigation features of the XPath "language" (though what a return value
is from a target I don't know other than "success" or "BuildException
thrown").
Following your example we could register (again as I suggested) special
functions for the "standard" conditionals, so the expression could look
like:
${cond: available("file", $myFile, "type", "file")}
(XPath variable reference syntax is a bit different from Ant's property
reference syntax: it simply uses a "$" to prefix the QName of a
registered variable: all Ant properties would have to be registered as
variables with the XPath context/infrastructure in some way, with
"illegal" characters translated into legal ones).
Having thought about it a bit more, it strikes me that we could have a
means of automatically generating appropriate functions, in the
appropriate namespaces (if needed), for *any* and *all* registered
tasks. E.g. a task "myTask" in a namespace defined for
"http://example.org/namespace"; with a prefix of "x" could be
automatically provided with an expression function that would understand
the possible attributes just like Ant does. This would then be callable
like:
${cond: x:myTask("myAttr", $example)}
XPath allows function calls to be nested, so the following is legal (and
easy to implement):
${cond: condition(and(available("file", $myFile), available("file",
$myDir, "type", "dir")))}
Finally, functions can also be defined that generate "data types" other
than booleans. That way it would even be possible to handle nested
elements (as implied by the above example). Another example (this isn't
really conditional, but you should get the idea):
${cond: copy("todir", $myDir, fileset("dir", $fromDir, include("name",
"**/*.java"), include("name", "**/*.jj")))}
Following this example it can be seen that the parameters to the
function are either a string (in which case it's an attribute name and
therefore followed by an attribute value - which must also resolve to a
string), or are a data type (in which case it corresponds to a nested
element and has no following value).
(I assume that an expression that uses a task that doesn't effectively
return a boolean value would return true if the task executed
successfully and false if the task threw a BuildException).
Anyway, that's my tuppence worth.
Phil :n)
On Mon, 2004-07-26 at 16:48, Jose Alberto Fernandez wrote:
> OK, I been giving some more background thinking on this issue.
>
> And at this point, I cannot find any reason why to use Xpath
> as the language for condition evaluation. The reason being that
> on most builds (if not all) how the execution flow goes does not depend
> on how the XML build file looks like but on external factors
> "Is such class available?", "Are this files uptodate?", "Is this file
> bigger that that one",
> "Is the value of this property the same as this or that?"
>
> So I fail to see what good does it do to use a language designed to
> simplify
> talking about the structure of a document (attributs and elements) where
> that is the least of our concerns.
>
> With this in mind, I have been thinking on Velocity as a better glue for
> this
> language. The idea being to provide access to the current conditionals
> via the Velocity context, for example, and hence allow callong them from
>
> Velocity. The context will provide a bridge between the Velocity syntax
> and the most common conditionals by means of, for example, velocimacros.
>
> I am also thinking on Conditionals providing a subinterface that allows
> simpler glueing into the evaluation engine. So we would be able to say
> something like:
>
> if="${cond: $available.att("file",
> ${myFile}).att("type","file")}" or
> if="${cond: $available.file(myFile).type("file")}"
>
> or something like that. This will require us going ahead with addig
> roles to
> the context know what conditionals are out there.
>
> Comments, thrashing, refining, how to's?
>
> Jose Alberto
>
> > -----Original Message-----
> > From: Phil Weighill-Smith [mailto:[EMAIL PROTECTED]
> > Sent: 22 July 2004 12:22
> > To: Ant Developers List
> > Subject: Re: new Task subclass
> >
> >
> > 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.
> >
> > 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()" ...
> >
> > 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.
> >
> > Phil :n)
> >
> > On Thu, 2004-07-22 at 11:47, Stefan Bodewig wrote:
> >
> > > On Thu, 22 Jul 2004, Jose Alberto Fernandez
> > > <[EMAIL PROTECTED]> wrote:
> > >
> > > > As per if/unless itself, I really would like to explore more what
> > > > some people have suggested about having a richer language
> > than just
> > > > set/unset.
> > >
> > > PropertyHelper?
> > >
> > > IOW, I think we already have the infrastructure needed to
> > do that in
> > > Ant's core.
> > >
> > > Stefan
> > >
> > >
> > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> > --
> > Phil Weighill-Smith <[EMAIL PROTECTED]>
> > Volantis Systems
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
--
Phil Weighill-Smith <[EMAIL PROTECTED]>
Volantis Systems
