Now for the larger question, Does everyone want expression support in
NAnt?
I definitely want it! I need it really badly. Currently I'm unable to check
some things correctly without expressions (without script or external
utility). Expression will be very easy in mine case.
It is:
foreach
PROTECTED]
Subject: Re: [nant-dev] SUMMARY: Expression Syntax
Now for the larger question, Does everyone want expression
support in
NAnt?
I definitely want it! I need it really badly. Currently I'm
unable to check some things correctly without expressions
(without script or external
AM
Subject: [nant-dev] SUMMARY: Expression Syntax
Hi Scott,
As you requested, here's a summary of expression evaluator discussion:
Ian, Gert, Martin - can you please correct me if I'm wrong anywhere in the
summary.
There are 2 questions
My first inclination is towards A for Q1. This would mean that all
expressions, and property expansions, are like this ${expr}, correct?
XSLT uses braces for inline evaluation in attributes and XPath variables are
$ prefixed. In our case it seems like once we start a expression block,
denoted by
Thanks for your opinion Scott.
Now for the larger question, Does everyone want expression support in
NAnt?
I think there are some real benefits to adding expression support. It will
make things much more flexible. But it also means that more complicated
and
possibly harder to read build
By adding expression support we are moving functionality from the tasks
(defined by xml) to the expression engine. Now I am starting to think
about
how to add support for extensions to the expression engine; just like I
think about how to add functionality by creating new tasks. This is the
Good point about side-effects. This does paint a clear distinction. But then
you get tasks like xmlpoke, with no corresponding xmlpeek; this might make
the user search around for the expression/function to use, or even assume
that this functionality does not exist.
I'm inclined to give this a day
Good point about side-effects. This does paint a clear distinction. But
then
you get tasks like xmlpoke, with no corresponding xmlpeek; this might make
the user search around for the expression/function to use, or even assume
that this functionality does not exist.
You're right. Perhaps
: Jaroslaw Kowalski [mailto:[EMAIL PROTECTED]
Sent: Monday, 8 December 2003 8:47 AM
To: Scott Hernandez; [EMAIL PROTECTED]
Subject: Re: [nant-dev] SUMMARY: Expression Syntax
Good point about side-effects. This does paint a clear distinction.
But
then
you get tasks like xmlpoke
To: Mitch Denny
Cc: [EMAIL PROTECTED]
Subject: Re: [nant-dev] SUMMARY: Expression Syntax
I don't think it is - is it ? Maybe the suggestion was that
xmlpeek could be implemented as a function rather than a task ie :
property name=foo value=${xmlpeek( 'somefile.xml',
'\\somexpathexpr
10 matches
Mail list logo
