--- Alexey Solofnenko <[EMAIL PROTECTED]> wrote:
> I think we need to restore old functionality,
> because it was done after
> 1.7 was released. Or it can be made smarter by
> checking if setValue()
> was called and use that value instead of return
> value. Again we need to
> decide if we want 100% backward compatibility or
> slightly less.
I guess at this point I'd just roll it back until we
can come up with a solution that pleases everyone.
-Matt
>
> - Alexey.
>
> Matt Benson wrote:
> > --- Alexey Solofnenko <[EMAIL PROTECTED]> wrote:
> >
> >
> >> Sorry about that. Personally I would prefer
> >> "expression" attribute to
> >> contain an expression itself - it is supposed to
> be
> >> simple.
> >>
> >>
> >
> > That still doesn't address the situation I
> mentioned,
> > whereby some arbitrary scripty stuff is done to
> > calculate a final result, then return it. It
> seems
> > that experience has shown we shouldn't
> discriminate
> > between an attribute and nested text. Maybe a
> > different attribute name would better express the
> > concept I am after.
> >
> > -Matt
> >
> >
> >> - Alexey.
> >>
> >> On 7/31/07, Matt Benson <[EMAIL PROTECTED]>
> >> wrote:
> >>
> >>> --- Alexey Solofnenko <[EMAIL PROTECTED]> wrote:
> >>>
> >>>
> >>>> It is just a thought - should ScriptFilter,
> >>>> ScriptMapper, ... also return a
> >>>> value instead of setting it?
> >>>>
> >>>>
> >>> mmmm.... I don't know! :) In hindsight maybe
> it
> >>> would have been better to leave this can of
> worms
> >>> unmolested rather than deal with these concepts
> of
> >>> consistency... I suppose that in either of
> those
> >>> cases it might well be reasonable to handle a
> >>>
> >> return
> >>
> >>> value. But with good old Python, what--you
> can't
> >>> execute arbitrary junk, return a value, and
> >>>
> >> consider
> >>
> >>> that an evaluation? Jython seems to be a pain
> >>> overall... seems like every time I have to deal
> >>>
> >> with
> >>
> >>> it there's a headache involved. If we do extend
> >>>
> >> this
> >>
> >>> concept, I suppose we could pull up "expression"
> >>>
> >> to
> >>
> >>> AbstractScriptComponent, and have evaluate()
> >>>
> >> delegate
> >>
> >>> to execute() and return null when expression ==
> >>> false... then any type that wanted to support a
> >>>
> >> return
> >>
> >>> value could just switch to calling evaluate and
> >>>
> >> prefer
> >>
> >>> a return value to whatever its "legacy"
> mechanisms
> >>> were. How does this sound?
> >>>
> >>> -Matt
> >>>
> >>>
> >>>> - 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)
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >
>
____________________________________________________________________________________
> >
> >>> Pinpoint customers who are looking for what you
> >>>
> >> sell.
> >>
> >>> http://searchmarketing.yahoo.com/
> >>>
> >>>
> >>>
> >
>
---------------------------------------------------------------------
> >
> >>> 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 <http://trelony.cjb.net/>
> Pleasant Hill, CA (GMT-8 usually)
>
____________________________________________________________________________________
Sick sense of humor? Visit Yahoo! TV's
Comedy with an Edge to see what's on, when.
http://tv.yahoo.com/collections/222
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
