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]
