It is just a thought - should ScriptFilter, ScriptMapper, ... also return a
value instead of setting it?
- Alexey.
On 7/31/07, Matt Benson <[EMAIL PROTECTED]> wrote:
>
>
> --- Alexey Solofnenko <[EMAIL PROTECTED]> wrote:
>
> > Old code was executing self.setValue() and the
> > current behaviour breaks
> > backward compatibility. I have tried old
> > ScriptCondition.eval() and it fixed
> > the problem. I think we should add "expression"
> > attribute to
> > AbstractScriptComponent and change it to use it with
> > evaluateScript(),
> > otherwise nested text will be executed with old
> > executeScript() call.
>
> Thanks for running this down, Alexey. I see where
> you're coming from with the "expression" attribute,
> though I'm not sure I agree it should live all the way
> up in AbstractScriptComponent, because we can't use it
> to automatically drive anything. I am going to add it
> to ScriptCondition directly; if we change our minds
> later pulling it up shouldn't cause any problems.
>
> -Matt
>
> >
> > - Alexey.
> >
> > On 7/31/07, Peter Reilly
> > <[EMAIL PROTECTED]> wrote:
> > >
> > > For BSF there are two methods to run a script:
> > > eval and exec,
> > >
> > > In ant 1.6.* the only method supported was exec.
> > Hence all
> > > the <script*> types called methods on self to set
> > the return
> > > value.
> > >
> > > For ant 1.7.0, I modified the scripting code to
> > allow access to
> > > eval and exec, but did not modify any calling
> > types to use
> > > eval rather than exec. (In fact I did not test the
> > eval on anything)
> > > I placed it here to allow expression handling from
> > property callbacks
> > > - something like <if test='${groovy: abc ==
> > "abc"}"> ..., but did
> > > not follow up.
> > >
> > > I assume that jython does not like a new line in
> > its expression.
> > >
> > > one can in python do
> > > a = 1
> > > if a > 0:
> > > b = 2
> > > however, one cannot do
> > > if #
> > > a > 0:
> > >
> > >
> > > ...
> > > So I think that this is a clear case of BC
> > problem.
> > > It would be nearly impossible to use
> > <scriptcondition> with
> > > jythton in it's current state.
> > >
> > >
> > > (I cannot test at the moment due to
> > (bsf/log4j/commons
> > > logging/jython.jar issues)
> > >
> > > Peter
> > >
> > >
> > >
> > > On 7/31/07, Dominique Devienne
> > <[EMAIL PROTECTED]> wrote:
> > > > On 7/31/07, Matt Benson <[EMAIL PROTECTED]>
> > wrote:
> > > > > <scriptcondition> originally behaved such that
> > a
> > > > > default value can be declared on the task as
> > an
> > > > > attribute, and the embedded script can set the
> > > > > condition value. I preserved this behavior,
> > but added
> > > > > a preference for a return value, if any, from
> > the
> > > > > script: again, on the basis that this seemed
> > a (more)
> > > > > natural behavior to me. DD, you said "not
> > returning a
> > > > > value is fine by you"... and that's what
> > > > > <scriptcondition> always did, and _should_
> > still
> > > > > allow... am _I_ missing anything (other than
> > whatever
> > > > > I've apparently done to break python
> > compatibility)?
> > > >
> > > > Ah, sorry, I meant that "not returning a value
> > is meaningless to me".
> > > > Sure, if a default value for the condition is
> > set as an attribute, why
> > > > not (although I don't see why that's necessary
> > or useful), but a
> > > > scriptcondition is supposed to be a script
> > fragment which returns a
> > > > boolean value, and I don't see the point of not
> > returning a value.
> > > > --DD
> > > >
> > > > PS: The error message could be nicer though ;-)
> > > >
> > > >
> >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail:
> > [EMAIL PROTECTED]
> > > > For additional commands, e-mail:
> > [EMAIL PROTECTED]
> > > >
> > > >
> > >
> > >
> >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> > [EMAIL PROTECTED]
> > > For additional commands, e-mail:
> > [EMAIL PROTECTED]
> > >
> > >
> >
> >
> > --
> > Alexey N. Solofnenko
> > Home: http://trelony.cjb.net/
> > Pleasant Hill, CA (GMT-8 usually)
> >
>
>
>
>
>
> ____________________________________________________________________________________
> Choose the right car based on your needs. Check out Yahoo! Autos new Car
> Finder tool.
> http://autos.yahoo.com/carfinder/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Alexey N. Solofnenko
Home: http://trelony.cjb.net/
Pleasant Hill, CA (GMT-8 usually)
