You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Adrian Crum <ad...@sandglass-software.com> on 2012/03/05 08:41:48 UTC
Re: Implementing JSR-223
I was thinking we could use something like ${[script:groovy]...}
${[script:jython]...} etc. I'm concerned that looking for a string
followed by a colon can lead to errors.
-Adrian
On 3/5/2012 6:22 AM, Jacopo Cappellato wrote:
> I would like to clarify that in this first pass I focused on "moving code around" keeping the same exact behavior currently implemented: now all the code that had a dependency on Groovy or Beanshell packages has been converted to be only dependent on ScriptUtil class.
> In order to implement JSR-223 we may have to change some of the current behavior (the different way Beanshell and Groovy are preparsed/executed) and also check if we can always assume that if the code inside of ${...} starts with a string (no spaces) followed by a colon (and a blank character?) then the string is the scripting language: I didn't check the impact on existing scripts but it should be easy to write a reg exp to find all of them (I expect that the number will be small) and modify them to be compatible with the convention. I intentionally didn't focus on this second step.
>
> Jacopo
>
> On Mar 4, 2012, at 10:27 PM, Jacques Le Roux wrote:
>
>> I must says I only cursorily reviewed the code Jacopo committed and did not look into JSR-223 details.
>> So I thought at some point you have to check which language wich is used?
>>
>> Like in
>> + if ("groovy".equals(language)) {
>> + if (scriptClass == null) {
>> + scriptClass = ScriptUtil.parseScript(language, script);
>> + }
>> + if (scriptClass != null) {
>> + result = InvokerHelper.createScript(scriptClass, GroovyUtil.getBinding(inputMap)).run();
>> + }
>> + } else if ("bsh".equals(language)) {
>> + result = BshUtil.eval(script, UtilMisc.makeMapWritable(inputMap));
>> + }
>>
>> In other words from Jacopo's code here, it seems you have to differentiate how scritps are parsed?
>>
>> Jacques
>>
>> From: "Adrian Crum"<ad...@sandglass-software.com>
>>> Groovy supports JSR-223, so there is no reason to treat it differently. My question has nothing to do with which scripting engine
>>> is supplied with OFBiz.
>>>
>>> -Adrian
>>>
>>> On 3/4/2012 8:43 PM, Jacques Le Roux wrote:
>>>> I don't want to interfer with Jacopo's answer, but I guess it's because Groovy will be implemented OOTB. The others could be but
>>>> Groovy is already part of the framework (the inital subject from Erwan was to completely remove BeanShell OOTB usage), I mean
>>>> it's the idea and what Jacopo said already.
>>>>
>>>> I second this idea. Everybody can use her/his preferred scripting language in custom projects. But using only one language OOTB
>>>> seems to be common sense. We chose groovy...
>>>>
>>>> Jacques
>>>>
>>>> From: "Adrian Crum"<ad...@sandglass-software.com>
>>>>> The code changes tested fine.
>>>>>
>>>>> I noticed in your code comments that Groovy should be handled independently from other scripting languages. Why do you think
>>>>> that?
>>>>>
>>>>> -Adrian
>>>>>
>>>>>
>>>>> On 3/4/2012 7:27 AM, Jacopo Cappellato wrote:
>>>>>> My changes are in commit 1296762
>>>>>>
>>>>>> Help with reviews and tests will be very much appreciated.
>>>>>>
>>>>>> Jacopo
>>>>>>
>>>>>> On Mar 3, 2012, at 1:45 PM, Jacopo Cappellato wrote:
>>>>>>
>>>>>>> On Mar 1, 2012, at 10:51 AM, Adrian Crum wrote:
>>>>>>>
>>>>>>>> As far as I know, most scripting engines have some sort of embedded cache. The problem will be that we can't clear the
>>>>>>>> embedded
>>>>>>>> cache like we can with our own cache implementation. I don't see that as a show stopper - it's mostly inconvenient.
>>>>>>>>
>>>>>>>> I can help out with the conversion. I don't think the task will be that hard.
>>>>>>> Adrian, FYI I am enhancing some of the existing framework code that uses the GroovyUtil class to simplify this task.
>>>>>>> I will commit my code changes today.
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Jacopo
>>>>>>>
>>>>>>>
>>>>>>>
Re: Implementing JSR-223
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
On Mar 5, 2012, at 8:57 AM, Adrian Crum wrote:
> Btw, expressions should go in the from-field attribute, not the value attribute.
Well, the mechanism value="${groovy: ...}" is actually used a lot currently; and in the from-field attribute the ${groovy: is not required.
Jacopo
Re: Implementing JSR-223
Posted by Upep à les7arts <up...@les7arts.com>.
From: "Nicolas Malin" <ma...@librenberry.net>
> Le 05/03/2012 10:08, Adrian Crum a écrit :
>> Because the value attribute is supposed to represent a string constant (that can be converted to another type via the type
>> attribute), and the from-field attribute is supposed to represent a variable.
>>
>> My preference is to have a from-expression attribute to make things clearer.
>
> Same opinion, the from-expression miss to separate the value origin:
I guess you meant from-field above ;o)
Jacques
> * from-field : provide only from existent context field
> * value : only given value (Parsing by the given type)
> * from-expression : calling script interface to resolve value.
>
>>
>> From my perspective, the main reason mini-language has such strange and quirky behavior is because the syntax has not been
>> clearly expressed or implemented.
>>
>> -Adrian
>>
>> On 3/5/2012 8:51 AM, Jacques Le Roux wrote:
>>> From: "Adrian Crum" <ad...@sandglass-software.com>
>>>> Okay, we can give it a try and see if we run into any problems.
>>>>
>>>> Btw, expressions should go in the from-field attribute, not the value attribute.
>>>
>>> Why? I'd prefer to stay the same than now. I agree it's a convention, but from-field makes less sense to me for evaluated
>>> expressions (being in a script or inlined)
>>>
>>> Jacques
>>>
>>>> -Adrian
>>>>
>>>> On 3/5/2012 7:53 AM, Jacopo Cappellato wrote:
>>>>> Yes, this is fine and I was thinking about a similar solution; however I would like to find a simpler convention because
>>>>> [script:groovy] is a lot of typing and could be difficult to read when the code in buried in the "value" attribute of a "set"
>>>>> element.
>>>>> Something like:
>>>>> ${script:jython code_here}
>>>>> ${script:groovy code_here}
>>>>> ${script: code_here} this could use the "default" language set in some properties file (i.e. "groovy"); this follows the
>>>>> "configuration by exception" pattern (specify the script only if you want to use a non default one).
>>>>>
>>>>> But we should also consider a shortcut where the "script" word is abbreviated, for example by the "s" word:
>>>>> ${s:jython code_here}
>>>>> ${s:groovy code_here}
>>>>> ${s: code_here}
>>>>>
>>>>> Jacopo
>>>>>
>>>>> On Mar 5, 2012, at 8:41 AM, Adrian Crum wrote:
>>>>>
>>>>>> I was thinking we could use something like ${[script:groovy]...} ${[script:jython]...} etc. I'm concerned that looking for a
>>>>>> string followed by a colon can lead to errors.
>>>>>>
>>>>>> -Adrian
>>>>>>
>>>>>> On 3/5/2012 6:22 AM, Jacopo Cappellato wrote:
>>>>>>> I would like to clarify that in this first pass I focused on "moving code around" keeping the same exact behavior currently
>>>>>>> implemented: now all the code that had a dependency on Groovy or Beanshell packages has been converted to be only dependent
>>>>>>> on
>>>>>>> ScriptUtil class.
>>>>>>> In order to implement JSR-223 we may have to change some of the current behavior (the different way Beanshell and Groovy are
>>>>>>> preparsed/executed) and also check if we can always assume that if the code inside of ${...} starts with a string (no
>>>>>>> spaces)
>>>>>>> followed by a colon (and a blank character?) then the string is the scripting language: I didn't check the impact on
>>>>>>> existing
>>>>>>> scripts but it should be easy to write a reg exp to find all of them (I expect that the number will be small) and modify
>>>>>>> them
>>>>>>> to be compatible with the convention. I intentionally didn't focus on this second step.
>>>>>>>
>>>>>>> Jacopo
>>>>>>>
>>>>>>> On Mar 4, 2012, at 10:27 PM, Jacques Le Roux wrote:
>>>>>>>
>>>>>>>> I must says I only cursorily reviewed the code Jacopo committed and did not look into JSR-223 details.
>>>>>>>> So I thought at some point you have to check which language wich is used?
>>>>>>>>
>>>>>>>> Like in
>>>>>>>> + if ("groovy".equals(language)) {
>>>>>>>> + if (scriptClass == null) {
>>>>>>>> + scriptClass = ScriptUtil.parseScript(language, script);
>>>>>>>> + }
>>>>>>>> + if (scriptClass != null) {
>>>>>>>> + result = InvokerHelper.createScript(scriptClass, GroovyUtil.getBinding(inputMap)).run();
>>>>>>>> + }
>>>>>>>> + } else if ("bsh".equals(language)) {
>>>>>>>> + result = BshUtil.eval(script, UtilMisc.makeMapWritable(inputMap));
>>>>>>>> + }
>>>>>>>>
>>>>>>>> In other words from Jacopo's code here, it seems you have to differentiate how scritps are parsed?
>>>>>>>>
>>>>>>>> Jacques
>>>>>>>>
>>>>>>>> From: "Adrian Crum"<ad...@sandglass-software.com>
>>>>>>>>> Groovy supports JSR-223, so there is no reason to treat it differently. My question has nothing to do with which scripting
>>>>>>>>> engine
>>>>>>>>> is supplied with OFBiz.
>>>>>>>>>
>>>>>>>>> -Adrian
>>>>>>>>>
>>>>>>>>> On 3/4/2012 8:43 PM, Jacques Le Roux wrote:
>>>>>>>>>> I don't want to interfer with Jacopo's answer, but I guess it's because Groovy will be implemented OOTB. The others could
>>>>>>>>>> be
>>>>>>>>>> but
>>>>>>>>>> Groovy is already part of the framework (the inital subject from Erwan was to completely remove BeanShell OOTB usage), I
>>>>>>>>>> mean
>>>>>>>>>> it's the idea and what Jacopo said already.
>>>>>>>>>>
>>>>>>>>>> I second this idea. Everybody can use her/his preferred scripting language in custom projects. But using only one
>>>>>>>>>> language
>>>>>>>>>> OOTB
>>>>>>>>>> seems to be common sense. We chose groovy...
>>>>>>>>>>
>>>>>>>>>> Jacques
>>>>>>>>>>
>>>>>>>>>> From: "Adrian Crum"<ad...@sandglass-software.com>
>>>>>>>>>>> The code changes tested fine.
>>>>>>>>>>>
>>>>>>>>>>> I noticed in your code comments that Groovy should be handled independently from other scripting languages. Why do you
>>>>>>>>>>> think
>>>>>>>>>>> that?
>>>>>>>>>>>
>>>>>>>>>>> -Adrian
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 3/4/2012 7:27 AM, Jacopo Cappellato wrote:
>>>>>>>>>>>> My changes are in commit 1296762
>>>>>>>>>>>>
>>>>>>>>>>>> Help with reviews and tests will be very much appreciated.
>>>>>>>>>>>>
>>>>>>>>>>>> Jacopo
>>>>>>>>>>>>
>>>>>>>>>>>> On Mar 3, 2012, at 1:45 PM, Jacopo Cappellato wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> On Mar 1, 2012, at 10:51 AM, Adrian Crum wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> As far as I know, most scripting engines have some sort of embedded cache. The problem will be that we can't clear
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> embedded
>>>>>>>>>>>>>> cache like we can with our own cache implementation. I don't see that as a show stopper - it's mostly inconvenient.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I can help out with the conversion. I don't think the task will be that hard.
>>>>>>>>>>>>> Adrian, FYI I am enhancing some of the existing framework code that uses the GroovyUtil class to simplify this task.
>>>>>>>>>>>>> I will commit my code changes today.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Jacopo
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>
>
> --
> Nicolas MALIN
> Consultant
> Tél : 06.17.66.40.06
> Site projet : http://www.neogia.org/
> -------
> Société LibrenBerry
> Tél : 02.48.02.56.12
> Site : http://www.librenberry.net/
>
Re: Implementing JSR-223
Posted by Nicolas Malin <ma...@librenberry.net>.
Le 05/03/2012 10:08, Adrian Crum a écrit :
> Because the value attribute is supposed to represent a string constant
> (that can be converted to another type via the type attribute), and
> the from-field attribute is supposed to represent a variable.
>
> My preference is to have a from-expression attribute to make things
> clearer.
Same opinion, the from-expression miss to separate the value origin:
* from-field : provide only from existent context field
* value : only given value (Parsing by the given type)
* from-expression : calling script interface to resolve value.
>
> From my perspective, the main reason mini-language has such strange
> and quirky behavior is because the syntax has not been clearly
> expressed or implemented.
>
> -Adrian
>
> On 3/5/2012 8:51 AM, Jacques Le Roux wrote:
>> From: "Adrian Crum" <ad...@sandglass-software.com>
>>> Okay, we can give it a try and see if we run into any problems.
>>>
>>> Btw, expressions should go in the from-field attribute, not the
>>> value attribute.
>>
>> Why? I'd prefer to stay the same than now. I agree it's a convention,
>> but from-field makes less sense to me for evaluated expressions
>> (being in a script or inlined)
>>
>> Jacques
>>
>>> -Adrian
>>>
>>> On 3/5/2012 7:53 AM, Jacopo Cappellato wrote:
>>>> Yes, this is fine and I was thinking about a similar solution;
>>>> however I would like to find a simpler convention because
>>>> [script:groovy] is a lot of typing and could be difficult to read
>>>> when the code in buried in the "value" attribute of a "set"
>>>> element.
>>>> Something like:
>>>> ${script:jython code_here}
>>>> ${script:groovy code_here}
>>>> ${script: code_here} this could use the "default" language set in
>>>> some properties file (i.e. "groovy"); this follows the
>>>> "configuration by exception" pattern (specify the script only if
>>>> you want to use a non default one).
>>>>
>>>> But we should also consider a shortcut where the "script" word is
>>>> abbreviated, for example by the "s" word:
>>>> ${s:jython code_here}
>>>> ${s:groovy code_here}
>>>> ${s: code_here}
>>>>
>>>> Jacopo
>>>>
>>>> On Mar 5, 2012, at 8:41 AM, Adrian Crum wrote:
>>>>
>>>>> I was thinking we could use something like ${[script:groovy]...}
>>>>> ${[script:jython]...} etc. I'm concerned that looking for a
>>>>> string followed by a colon can lead to errors.
>>>>>
>>>>> -Adrian
>>>>>
>>>>> On 3/5/2012 6:22 AM, Jacopo Cappellato wrote:
>>>>>> I would like to clarify that in this first pass I focused on
>>>>>> "moving code around" keeping the same exact behavior currently
>>>>>> implemented: now all the code that had a dependency on Groovy or
>>>>>> Beanshell packages has been converted to be only dependent on
>>>>>> ScriptUtil class.
>>>>>> In order to implement JSR-223 we may have to change some of the
>>>>>> current behavior (the different way Beanshell and Groovy are
>>>>>> preparsed/executed) and also check if we can always assume that
>>>>>> if the code inside of ${...} starts with a string (no spaces)
>>>>>> followed by a colon (and a blank character?) then the string is
>>>>>> the scripting language: I didn't check the impact on existing
>>>>>> scripts but it should be easy to write a reg exp to find all of
>>>>>> them (I expect that the number will be small) and modify them
>>>>>> to be compatible with the convention. I intentionally didn't
>>>>>> focus on this second step.
>>>>>>
>>>>>> Jacopo
>>>>>>
>>>>>> On Mar 4, 2012, at 10:27 PM, Jacques Le Roux wrote:
>>>>>>
>>>>>>> I must says I only cursorily reviewed the code Jacopo committed
>>>>>>> and did not look into JSR-223 details.
>>>>>>> So I thought at some point you have to check which language wich
>>>>>>> is used?
>>>>>>>
>>>>>>> Like in
>>>>>>> + if ("groovy".equals(language)) {
>>>>>>> + if (scriptClass == null) {
>>>>>>> + scriptClass = ScriptUtil.parseScript(language,
>>>>>>> script);
>>>>>>> + }
>>>>>>> + if (scriptClass != null) {
>>>>>>> + result =
>>>>>>> InvokerHelper.createScript(scriptClass,
>>>>>>> GroovyUtil.getBinding(inputMap)).run();
>>>>>>> + }
>>>>>>> + } else if ("bsh".equals(language)) {
>>>>>>> + result = BshUtil.eval(script,
>>>>>>> UtilMisc.makeMapWritable(inputMap));
>>>>>>> + }
>>>>>>>
>>>>>>> In other words from Jacopo's code here, it seems you have to
>>>>>>> differentiate how scritps are parsed?
>>>>>>>
>>>>>>> Jacques
>>>>>>>
>>>>>>> From: "Adrian Crum"<ad...@sandglass-software.com>
>>>>>>>> Groovy supports JSR-223, so there is no reason to treat it
>>>>>>>> differently. My question has nothing to do with which scripting
>>>>>>>> engine
>>>>>>>> is supplied with OFBiz.
>>>>>>>>
>>>>>>>> -Adrian
>>>>>>>>
>>>>>>>> On 3/4/2012 8:43 PM, Jacques Le Roux wrote:
>>>>>>>>> I don't want to interfer with Jacopo's answer, but I guess
>>>>>>>>> it's because Groovy will be implemented OOTB. The others could be
>>>>>>>>> but
>>>>>>>>> Groovy is already part of the framework (the inital subject
>>>>>>>>> from Erwan was to completely remove BeanShell OOTB usage), I
>>>>>>>>> mean
>>>>>>>>> it's the idea and what Jacopo said already.
>>>>>>>>>
>>>>>>>>> I second this idea. Everybody can use her/his preferred
>>>>>>>>> scripting language in custom projects. But using only one
>>>>>>>>> language
>>>>>>>>> OOTB
>>>>>>>>> seems to be common sense. We chose groovy...
>>>>>>>>>
>>>>>>>>> Jacques
>>>>>>>>>
>>>>>>>>> From: "Adrian Crum"<ad...@sandglass-software.com>
>>>>>>>>>> The code changes tested fine.
>>>>>>>>>>
>>>>>>>>>> I noticed in your code comments that Groovy should be handled
>>>>>>>>>> independently from other scripting languages. Why do you
>>>>>>>>>> think
>>>>>>>>>> that?
>>>>>>>>>>
>>>>>>>>>> -Adrian
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 3/4/2012 7:27 AM, Jacopo Cappellato wrote:
>>>>>>>>>>> My changes are in commit 1296762
>>>>>>>>>>>
>>>>>>>>>>> Help with reviews and tests will be very much appreciated.
>>>>>>>>>>>
>>>>>>>>>>> Jacopo
>>>>>>>>>>>
>>>>>>>>>>> On Mar 3, 2012, at 1:45 PM, Jacopo Cappellato wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On Mar 1, 2012, at 10:51 AM, Adrian Crum wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> As far as I know, most scripting engines have some sort of
>>>>>>>>>>>>> embedded cache. The problem will be that we can't clear the
>>>>>>>>>>>>> embedded
>>>>>>>>>>>>> cache like we can with our own cache implementation. I
>>>>>>>>>>>>> don't see that as a show stopper - it's mostly inconvenient.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I can help out with the conversion. I don't think the task
>>>>>>>>>>>>> will be that hard.
>>>>>>>>>>>> Adrian, FYI I am enhancing some of the existing framework
>>>>>>>>>>>> code that uses the GroovyUtil class to simplify this task.
>>>>>>>>>>>> I will commit my code changes today.
>>>>>>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>>
>>>>>>>>>>>> Jacopo
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
--
Nicolas MALIN
Consultant
Tél : 06.17.66.40.06
Site projet : http://www.neogia.org/
-------
Société LibrenBerry
Tél : 02.48.02.56.12
Site : http://www.librenberry.net/
Re: Implementing JSR-223
Posted by Jacques Le Roux <ja...@les7arts.com>.
Mmm... from-expression indeed.... This remembered me a discussion we had already
http://markmail.org/message/dzljmdhg2c3i52aq
No time to re-read at the moment, but yes from-expression sounds good to me and not that hard to change in current code.
Jacques
From: "Adrian Crum" <ad...@sandglass-software.com>
> Because the value attribute is supposed to represent a string constant
> (that can be converted to another type via the type attribute), and the
> from-field attribute is supposed to represent a variable.
>
> My preference is to have a from-expression attribute to make things clearer.
>
> From my perspective, the main reason mini-language has such strange and
> quirky behavior is because the syntax has not been clearly expressed or
> implemented.
>
> -Adrian
>
> On 3/5/2012 8:51 AM, Jacques Le Roux wrote:
>> From: "Adrian Crum" <ad...@sandglass-software.com>
>>> Okay, we can give it a try and see if we run into any problems.
>>>
>>> Btw, expressions should go in the from-field attribute, not the value
>>> attribute.
>>
>> Why? I'd prefer to stay the same than now. I agree it's a convention,
>> but from-field makes less sense to me for evaluated expressions (being
>> in a script or inlined)
>>
>> Jacques
>>
>>> -Adrian
>>>
>>> On 3/5/2012 7:53 AM, Jacopo Cappellato wrote:
>>>> Yes, this is fine and I was thinking about a similar solution;
>>>> however I would like to find a simpler convention because
>>>> [script:groovy] is a lot of typing and could be difficult to read
>>>> when the code in buried in the "value" attribute of a "set"
>>>> element.
>>>> Something like:
>>>> ${script:jython code_here}
>>>> ${script:groovy code_here}
>>>> ${script: code_here} this could use the "default" language set in
>>>> some properties file (i.e. "groovy"); this follows the
>>>> "configuration by exception" pattern (specify the script only if you
>>>> want to use a non default one).
>>>>
>>>> But we should also consider a shortcut where the "script" word is
>>>> abbreviated, for example by the "s" word:
>>>> ${s:jython code_here}
>>>> ${s:groovy code_here}
>>>> ${s: code_here}
>>>>
>>>> Jacopo
>>>>
>>>> On Mar 5, 2012, at 8:41 AM, Adrian Crum wrote:
>>>>
>>>>> I was thinking we could use something like ${[script:groovy]...}
>>>>> ${[script:jython]...} etc. I'm concerned that looking for a
>>>>> string followed by a colon can lead to errors.
>>>>>
>>>>> -Adrian
>>>>>
>>>>> On 3/5/2012 6:22 AM, Jacopo Cappellato wrote:
>>>>>> I would like to clarify that in this first pass I focused on
>>>>>> "moving code around" keeping the same exact behavior currently
>>>>>> implemented: now all the code that had a dependency on Groovy or
>>>>>> Beanshell packages has been converted to be only dependent on
>>>>>> ScriptUtil class.
>>>>>> In order to implement JSR-223 we may have to change some of the
>>>>>> current behavior (the different way Beanshell and Groovy are
>>>>>> preparsed/executed) and also check if we can always assume that if
>>>>>> the code inside of ${...} starts with a string (no spaces)
>>>>>> followed by a colon (and a blank character?) then the string is
>>>>>> the scripting language: I didn't check the impact on existing
>>>>>> scripts but it should be easy to write a reg exp to find all of
>>>>>> them (I expect that the number will be small) and modify them
>>>>>> to be compatible with the convention. I intentionally didn't focus
>>>>>> on this second step.
>>>>>>
>>>>>> Jacopo
>>>>>>
>>>>>> On Mar 4, 2012, at 10:27 PM, Jacques Le Roux wrote:
>>>>>>
>>>>>>> I must says I only cursorily reviewed the code Jacopo committed
>>>>>>> and did not look into JSR-223 details.
>>>>>>> So I thought at some point you have to check which language wich
>>>>>>> is used?
>>>>>>>
>>>>>>> Like in
>>>>>>> + if ("groovy".equals(language)) {
>>>>>>> + if (scriptClass == null) {
>>>>>>> + scriptClass = ScriptUtil.parseScript(language,
>>>>>>> script);
>>>>>>> + }
>>>>>>> + if (scriptClass != null) {
>>>>>>> + result = InvokerHelper.createScript(scriptClass,
>>>>>>> GroovyUtil.getBinding(inputMap)).run();
>>>>>>> + }
>>>>>>> + } else if ("bsh".equals(language)) {
>>>>>>> + result = BshUtil.eval(script,
>>>>>>> UtilMisc.makeMapWritable(inputMap));
>>>>>>> + }
>>>>>>>
>>>>>>> In other words from Jacopo's code here, it seems you have to
>>>>>>> differentiate how scritps are parsed?
>>>>>>>
>>>>>>> Jacques
>>>>>>>
>>>>>>> From: "Adrian Crum"<ad...@sandglass-software.com>
>>>>>>>> Groovy supports JSR-223, so there is no reason to treat it
>>>>>>>> differently. My question has nothing to do with which scripting
>>>>>>>> engine
>>>>>>>> is supplied with OFBiz.
>>>>>>>>
>>>>>>>> -Adrian
>>>>>>>>
>>>>>>>> On 3/4/2012 8:43 PM, Jacques Le Roux wrote:
>>>>>>>>> I don't want to interfer with Jacopo's answer, but I guess it's
>>>>>>>>> because Groovy will be implemented OOTB. The others could be
>>>>>>>>> but
>>>>>>>>> Groovy is already part of the framework (the inital subject
>>>>>>>>> from Erwan was to completely remove BeanShell OOTB usage), I
>>>>>>>>> mean
>>>>>>>>> it's the idea and what Jacopo said already.
>>>>>>>>>
>>>>>>>>> I second this idea. Everybody can use her/his preferred
>>>>>>>>> scripting language in custom projects. But using only one language
>>>>>>>>> OOTB
>>>>>>>>> seems to be common sense. We chose groovy...
>>>>>>>>>
>>>>>>>>> Jacques
>>>>>>>>>
>>>>>>>>> From: "Adrian Crum"<ad...@sandglass-software.com>
>>>>>>>>>> The code changes tested fine.
>>>>>>>>>>
>>>>>>>>>> I noticed in your code comments that Groovy should be handled
>>>>>>>>>> independently from other scripting languages. Why do you
>>>>>>>>>> think
>>>>>>>>>> that?
>>>>>>>>>>
>>>>>>>>>> -Adrian
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 3/4/2012 7:27 AM, Jacopo Cappellato wrote:
>>>>>>>>>>> My changes are in commit 1296762
>>>>>>>>>>>
>>>>>>>>>>> Help with reviews and tests will be very much appreciated.
>>>>>>>>>>>
>>>>>>>>>>> Jacopo
>>>>>>>>>>>
>>>>>>>>>>> On Mar 3, 2012, at 1:45 PM, Jacopo Cappellato wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On Mar 1, 2012, at 10:51 AM, Adrian Crum wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> As far as I know, most scripting engines have some sort of
>>>>>>>>>>>>> embedded cache. The problem will be that we can't clear the
>>>>>>>>>>>>> embedded
>>>>>>>>>>>>> cache like we can with our own cache implementation. I
>>>>>>>>>>>>> don't see that as a show stopper - it's mostly inconvenient.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I can help out with the conversion. I don't think the task
>>>>>>>>>>>>> will be that hard.
>>>>>>>>>>>> Adrian, FYI I am enhancing some of the existing framework
>>>>>>>>>>>> code that uses the GroovyUtil class to simplify this task.
>>>>>>>>>>>> I will commit my code changes today.
>>>>>>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>>
>>>>>>>>>>>> Jacopo
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
Re: Implementing JSR-223
Posted by Adrian Crum <ad...@sandglass-software.com>.
Because the value attribute is supposed to represent a string constant
(that can be converted to another type via the type attribute), and the
from-field attribute is supposed to represent a variable.
My preference is to have a from-expression attribute to make things clearer.
From my perspective, the main reason mini-language has such strange and
quirky behavior is because the syntax has not been clearly expressed or
implemented.
-Adrian
On 3/5/2012 8:51 AM, Jacques Le Roux wrote:
> From: "Adrian Crum" <ad...@sandglass-software.com>
>> Okay, we can give it a try and see if we run into any problems.
>>
>> Btw, expressions should go in the from-field attribute, not the value
>> attribute.
>
> Why? I'd prefer to stay the same than now. I agree it's a convention,
> but from-field makes less sense to me for evaluated expressions (being
> in a script or inlined)
>
> Jacques
>
>> -Adrian
>>
>> On 3/5/2012 7:53 AM, Jacopo Cappellato wrote:
>>> Yes, this is fine and I was thinking about a similar solution;
>>> however I would like to find a simpler convention because
>>> [script:groovy] is a lot of typing and could be difficult to read
>>> when the code in buried in the "value" attribute of a "set"
>>> element.
>>> Something like:
>>> ${script:jython code_here}
>>> ${script:groovy code_here}
>>> ${script: code_here} this could use the "default" language set in
>>> some properties file (i.e. "groovy"); this follows the
>>> "configuration by exception" pattern (specify the script only if you
>>> want to use a non default one).
>>>
>>> But we should also consider a shortcut where the "script" word is
>>> abbreviated, for example by the "s" word:
>>> ${s:jython code_here}
>>> ${s:groovy code_here}
>>> ${s: code_here}
>>>
>>> Jacopo
>>>
>>> On Mar 5, 2012, at 8:41 AM, Adrian Crum wrote:
>>>
>>>> I was thinking we could use something like ${[script:groovy]...}
>>>> ${[script:jython]...} etc. I'm concerned that looking for a
>>>> string followed by a colon can lead to errors.
>>>>
>>>> -Adrian
>>>>
>>>> On 3/5/2012 6:22 AM, Jacopo Cappellato wrote:
>>>>> I would like to clarify that in this first pass I focused on
>>>>> "moving code around" keeping the same exact behavior currently
>>>>> implemented: now all the code that had a dependency on Groovy or
>>>>> Beanshell packages has been converted to be only dependent on
>>>>> ScriptUtil class.
>>>>> In order to implement JSR-223 we may have to change some of the
>>>>> current behavior (the different way Beanshell and Groovy are
>>>>> preparsed/executed) and also check if we can always assume that if
>>>>> the code inside of ${...} starts with a string (no spaces)
>>>>> followed by a colon (and a blank character?) then the string is
>>>>> the scripting language: I didn't check the impact on existing
>>>>> scripts but it should be easy to write a reg exp to find all of
>>>>> them (I expect that the number will be small) and modify them
>>>>> to be compatible with the convention. I intentionally didn't focus
>>>>> on this second step.
>>>>>
>>>>> Jacopo
>>>>>
>>>>> On Mar 4, 2012, at 10:27 PM, Jacques Le Roux wrote:
>>>>>
>>>>>> I must says I only cursorily reviewed the code Jacopo committed
>>>>>> and did not look into JSR-223 details.
>>>>>> So I thought at some point you have to check which language wich
>>>>>> is used?
>>>>>>
>>>>>> Like in
>>>>>> + if ("groovy".equals(language)) {
>>>>>> + if (scriptClass == null) {
>>>>>> + scriptClass = ScriptUtil.parseScript(language,
>>>>>> script);
>>>>>> + }
>>>>>> + if (scriptClass != null) {
>>>>>> + result = InvokerHelper.createScript(scriptClass,
>>>>>> GroovyUtil.getBinding(inputMap)).run();
>>>>>> + }
>>>>>> + } else if ("bsh".equals(language)) {
>>>>>> + result = BshUtil.eval(script,
>>>>>> UtilMisc.makeMapWritable(inputMap));
>>>>>> + }
>>>>>>
>>>>>> In other words from Jacopo's code here, it seems you have to
>>>>>> differentiate how scritps are parsed?
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>> From: "Adrian Crum"<ad...@sandglass-software.com>
>>>>>>> Groovy supports JSR-223, so there is no reason to treat it
>>>>>>> differently. My question has nothing to do with which scripting
>>>>>>> engine
>>>>>>> is supplied with OFBiz.
>>>>>>>
>>>>>>> -Adrian
>>>>>>>
>>>>>>> On 3/4/2012 8:43 PM, Jacques Le Roux wrote:
>>>>>>>> I don't want to interfer with Jacopo's answer, but I guess it's
>>>>>>>> because Groovy will be implemented OOTB. The others could be
>>>>>>>> but
>>>>>>>> Groovy is already part of the framework (the inital subject
>>>>>>>> from Erwan was to completely remove BeanShell OOTB usage), I
>>>>>>>> mean
>>>>>>>> it's the idea and what Jacopo said already.
>>>>>>>>
>>>>>>>> I second this idea. Everybody can use her/his preferred
>>>>>>>> scripting language in custom projects. But using only one language
>>>>>>>> OOTB
>>>>>>>> seems to be common sense. We chose groovy...
>>>>>>>>
>>>>>>>> Jacques
>>>>>>>>
>>>>>>>> From: "Adrian Crum"<ad...@sandglass-software.com>
>>>>>>>>> The code changes tested fine.
>>>>>>>>>
>>>>>>>>> I noticed in your code comments that Groovy should be handled
>>>>>>>>> independently from other scripting languages. Why do you
>>>>>>>>> think
>>>>>>>>> that?
>>>>>>>>>
>>>>>>>>> -Adrian
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 3/4/2012 7:27 AM, Jacopo Cappellato wrote:
>>>>>>>>>> My changes are in commit 1296762
>>>>>>>>>>
>>>>>>>>>> Help with reviews and tests will be very much appreciated.
>>>>>>>>>>
>>>>>>>>>> Jacopo
>>>>>>>>>>
>>>>>>>>>> On Mar 3, 2012, at 1:45 PM, Jacopo Cappellato wrote:
>>>>>>>>>>
>>>>>>>>>>> On Mar 1, 2012, at 10:51 AM, Adrian Crum wrote:
>>>>>>>>>>>
>>>>>>>>>>>> As far as I know, most scripting engines have some sort of
>>>>>>>>>>>> embedded cache. The problem will be that we can't clear the
>>>>>>>>>>>> embedded
>>>>>>>>>>>> cache like we can with our own cache implementation. I
>>>>>>>>>>>> don't see that as a show stopper - it's mostly inconvenient.
>>>>>>>>>>>>
>>>>>>>>>>>> I can help out with the conversion. I don't think the task
>>>>>>>>>>>> will be that hard.
>>>>>>>>>>> Adrian, FYI I am enhancing some of the existing framework
>>>>>>>>>>> code that uses the GroovyUtil class to simplify this task.
>>>>>>>>>>> I will commit my code changes today.
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>>
>>>>>>>>>>> Jacopo
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
Re: Implementing JSR-223
Posted by Jacques Le Roux <ja...@les7arts.com>.
From: "Adrian Crum" <ad...@sandglass-software.com>
> Okay, we can give it a try and see if we run into any problems.
>
> Btw, expressions should go in the from-field attribute, not the value attribute.
Why? I'd prefer to stay the same than now. I agree it's a convention, but from-field makes less sense to me for evaluated
expressions (being in a script or inlined)
Jacques
> -Adrian
>
> On 3/5/2012 7:53 AM, Jacopo Cappellato wrote:
>> Yes, this is fine and I was thinking about a similar solution; however I would like to find a simpler convention because
>> [script:groovy] is a lot of typing and could be difficult to read when the code in buried in the "value" attribute of a "set"
>> element.
>> Something like:
>> ${script:jython code_here}
>> ${script:groovy code_here}
>> ${script: code_here} this could use the "default" language set in some properties file (i.e. "groovy"); this follows the
>> "configuration by exception" pattern (specify the script only if you want to use a non default one).
>>
>> But we should also consider a shortcut where the "script" word is abbreviated, for example by the "s" word:
>> ${s:jython code_here}
>> ${s:groovy code_here}
>> ${s: code_here}
>>
>> Jacopo
>>
>> On Mar 5, 2012, at 8:41 AM, Adrian Crum wrote:
>>
>>> I was thinking we could use something like ${[script:groovy]...} ${[script:jython]...} etc. I'm concerned that looking for a
>>> string followed by a colon can lead to errors.
>>>
>>> -Adrian
>>>
>>> On 3/5/2012 6:22 AM, Jacopo Cappellato wrote:
>>>> I would like to clarify that in this first pass I focused on "moving code around" keeping the same exact behavior currently
>>>> implemented: now all the code that had a dependency on Groovy or Beanshell packages has been converted to be only dependent on
>>>> ScriptUtil class.
>>>> In order to implement JSR-223 we may have to change some of the current behavior (the different way Beanshell and Groovy are
>>>> preparsed/executed) and also check if we can always assume that if the code inside of ${...} starts with a string (no spaces)
>>>> followed by a colon (and a blank character?) then the string is the scripting language: I didn't check the impact on existing
>>>> scripts but it should be easy to write a reg exp to find all of them (I expect that the number will be small) and modify them
>>>> to be compatible with the convention. I intentionally didn't focus on this second step.
>>>>
>>>> Jacopo
>>>>
>>>> On Mar 4, 2012, at 10:27 PM, Jacques Le Roux wrote:
>>>>
>>>>> I must says I only cursorily reviewed the code Jacopo committed and did not look into JSR-223 details.
>>>>> So I thought at some point you have to check which language wich is used?
>>>>>
>>>>> Like in
>>>>> + if ("groovy".equals(language)) {
>>>>> + if (scriptClass == null) {
>>>>> + scriptClass = ScriptUtil.parseScript(language, script);
>>>>> + }
>>>>> + if (scriptClass != null) {
>>>>> + result = InvokerHelper.createScript(scriptClass, GroovyUtil.getBinding(inputMap)).run();
>>>>> + }
>>>>> + } else if ("bsh".equals(language)) {
>>>>> + result = BshUtil.eval(script, UtilMisc.makeMapWritable(inputMap));
>>>>> + }
>>>>>
>>>>> In other words from Jacopo's code here, it seems you have to differentiate how scritps are parsed?
>>>>>
>>>>> Jacques
>>>>>
>>>>> From: "Adrian Crum"<ad...@sandglass-software.com>
>>>>>> Groovy supports JSR-223, so there is no reason to treat it differently. My question has nothing to do with which scripting
>>>>>> engine
>>>>>> is supplied with OFBiz.
>>>>>>
>>>>>> -Adrian
>>>>>>
>>>>>> On 3/4/2012 8:43 PM, Jacques Le Roux wrote:
>>>>>>> I don't want to interfer with Jacopo's answer, but I guess it's because Groovy will be implemented OOTB. The others could be
>>>>>>> but
>>>>>>> Groovy is already part of the framework (the inital subject from Erwan was to completely remove BeanShell OOTB usage), I
>>>>>>> mean
>>>>>>> it's the idea and what Jacopo said already.
>>>>>>>
>>>>>>> I second this idea. Everybody can use her/his preferred scripting language in custom projects. But using only one language
>>>>>>> OOTB
>>>>>>> seems to be common sense. We chose groovy...
>>>>>>>
>>>>>>> Jacques
>>>>>>>
>>>>>>> From: "Adrian Crum"<ad...@sandglass-software.com>
>>>>>>>> The code changes tested fine.
>>>>>>>>
>>>>>>>> I noticed in your code comments that Groovy should be handled independently from other scripting languages. Why do you
>>>>>>>> think
>>>>>>>> that?
>>>>>>>>
>>>>>>>> -Adrian
>>>>>>>>
>>>>>>>>
>>>>>>>> On 3/4/2012 7:27 AM, Jacopo Cappellato wrote:
>>>>>>>>> My changes are in commit 1296762
>>>>>>>>>
>>>>>>>>> Help with reviews and tests will be very much appreciated.
>>>>>>>>>
>>>>>>>>> Jacopo
>>>>>>>>>
>>>>>>>>> On Mar 3, 2012, at 1:45 PM, Jacopo Cappellato wrote:
>>>>>>>>>
>>>>>>>>>> On Mar 1, 2012, at 10:51 AM, Adrian Crum wrote:
>>>>>>>>>>
>>>>>>>>>>> As far as I know, most scripting engines have some sort of embedded cache. The problem will be that we can't clear the
>>>>>>>>>>> embedded
>>>>>>>>>>> cache like we can with our own cache implementation. I don't see that as a show stopper - it's mostly inconvenient.
>>>>>>>>>>>
>>>>>>>>>>> I can help out with the conversion. I don't think the task will be that hard.
>>>>>>>>>> Adrian, FYI I am enhancing some of the existing framework code that uses the GroovyUtil class to simplify this task.
>>>>>>>>>> I will commit my code changes today.
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>>
>>>>>>>>>> Jacopo
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
Re: Implementing JSR-223
Posted by Adrian Crum <ad...@sandglass-software.com>.
Okay, we can give it a try and see if we run into any problems.
Btw, expressions should go in the from-field attribute, not the value
attribute.
-Adrian
On 3/5/2012 7:53 AM, Jacopo Cappellato wrote:
> Yes, this is fine and I was thinking about a similar solution; however I would like to find a simpler convention because [script:groovy] is a lot of typing and could be difficult to read when the code in buried in the "value" attribute of a "set" element.
> Something like:
> ${script:jython code_here}
> ${script:groovy code_here}
> ${script: code_here} this could use the "default" language set in some properties file (i.e. "groovy"); this follows the "configuration by exception" pattern (specify the script only if you want to use a non default one).
>
> But we should also consider a shortcut where the "script" word is abbreviated, for example by the "s" word:
> ${s:jython code_here}
> ${s:groovy code_here}
> ${s: code_here}
>
> Jacopo
>
> On Mar 5, 2012, at 8:41 AM, Adrian Crum wrote:
>
>> I was thinking we could use something like ${[script:groovy]...} ${[script:jython]...} etc. I'm concerned that looking for a string followed by a colon can lead to errors.
>>
>> -Adrian
>>
>> On 3/5/2012 6:22 AM, Jacopo Cappellato wrote:
>>> I would like to clarify that in this first pass I focused on "moving code around" keeping the same exact behavior currently implemented: now all the code that had a dependency on Groovy or Beanshell packages has been converted to be only dependent on ScriptUtil class.
>>> In order to implement JSR-223 we may have to change some of the current behavior (the different way Beanshell and Groovy are preparsed/executed) and also check if we can always assume that if the code inside of ${...} starts with a string (no spaces) followed by a colon (and a blank character?) then the string is the scripting language: I didn't check the impact on existing scripts but it should be easy to write a reg exp to find all of them (I expect that the number will be small) and modify them to be compatible with the convention. I intentionally didn't focus on this second step.
>>>
>>> Jacopo
>>>
>>> On Mar 4, 2012, at 10:27 PM, Jacques Le Roux wrote:
>>>
>>>> I must says I only cursorily reviewed the code Jacopo committed and did not look into JSR-223 details.
>>>> So I thought at some point you have to check which language wich is used?
>>>>
>>>> Like in
>>>> + if ("groovy".equals(language)) {
>>>> + if (scriptClass == null) {
>>>> + scriptClass = ScriptUtil.parseScript(language, script);
>>>> + }
>>>> + if (scriptClass != null) {
>>>> + result = InvokerHelper.createScript(scriptClass, GroovyUtil.getBinding(inputMap)).run();
>>>> + }
>>>> + } else if ("bsh".equals(language)) {
>>>> + result = BshUtil.eval(script, UtilMisc.makeMapWritable(inputMap));
>>>> + }
>>>>
>>>> In other words from Jacopo's code here, it seems you have to differentiate how scritps are parsed?
>>>>
>>>> Jacques
>>>>
>>>> From: "Adrian Crum"<ad...@sandglass-software.com>
>>>>> Groovy supports JSR-223, so there is no reason to treat it differently. My question has nothing to do with which scripting engine
>>>>> is supplied with OFBiz.
>>>>>
>>>>> -Adrian
>>>>>
>>>>> On 3/4/2012 8:43 PM, Jacques Le Roux wrote:
>>>>>> I don't want to interfer with Jacopo's answer, but I guess it's because Groovy will be implemented OOTB. The others could be but
>>>>>> Groovy is already part of the framework (the inital subject from Erwan was to completely remove BeanShell OOTB usage), I mean
>>>>>> it's the idea and what Jacopo said already.
>>>>>>
>>>>>> I second this idea. Everybody can use her/his preferred scripting language in custom projects. But using only one language OOTB
>>>>>> seems to be common sense. We chose groovy...
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>> From: "Adrian Crum"<ad...@sandglass-software.com>
>>>>>>> The code changes tested fine.
>>>>>>>
>>>>>>> I noticed in your code comments that Groovy should be handled independently from other scripting languages. Why do you think
>>>>>>> that?
>>>>>>>
>>>>>>> -Adrian
>>>>>>>
>>>>>>>
>>>>>>> On 3/4/2012 7:27 AM, Jacopo Cappellato wrote:
>>>>>>>> My changes are in commit 1296762
>>>>>>>>
>>>>>>>> Help with reviews and tests will be very much appreciated.
>>>>>>>>
>>>>>>>> Jacopo
>>>>>>>>
>>>>>>>> On Mar 3, 2012, at 1:45 PM, Jacopo Cappellato wrote:
>>>>>>>>
>>>>>>>>> On Mar 1, 2012, at 10:51 AM, Adrian Crum wrote:
>>>>>>>>>
>>>>>>>>>> As far as I know, most scripting engines have some sort of embedded cache. The problem will be that we can't clear the
>>>>>>>>>> embedded
>>>>>>>>>> cache like we can with our own cache implementation. I don't see that as a show stopper - it's mostly inconvenient.
>>>>>>>>>>
>>>>>>>>>> I can help out with the conversion. I don't think the task will be that hard.
>>>>>>>>> Adrian, FYI I am enhancing some of the existing framework code that uses the GroovyUtil class to simplify this task.
>>>>>>>>> I will commit my code changes today.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>>
>>>>>>>>> Jacopo
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
Re: Implementing JSR-223
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
Yes, this is fine and I was thinking about a similar solution; however I would like to find a simpler convention because [script:groovy] is a lot of typing and could be difficult to read when the code in buried in the "value" attribute of a "set" element.
Something like:
${script:jython code_here}
${script:groovy code_here}
${script: code_here} this could use the "default" language set in some properties file (i.e. "groovy"); this follows the "configuration by exception" pattern (specify the script only if you want to use a non default one).
But we should also consider a shortcut where the "script" word is abbreviated, for example by the "s" word:
${s:jython code_here}
${s:groovy code_here}
${s: code_here}
Jacopo
On Mar 5, 2012, at 8:41 AM, Adrian Crum wrote:
> I was thinking we could use something like ${[script:groovy]...} ${[script:jython]...} etc. I'm concerned that looking for a string followed by a colon can lead to errors.
>
> -Adrian
>
> On 3/5/2012 6:22 AM, Jacopo Cappellato wrote:
>> I would like to clarify that in this first pass I focused on "moving code around" keeping the same exact behavior currently implemented: now all the code that had a dependency on Groovy or Beanshell packages has been converted to be only dependent on ScriptUtil class.
>> In order to implement JSR-223 we may have to change some of the current behavior (the different way Beanshell and Groovy are preparsed/executed) and also check if we can always assume that if the code inside of ${...} starts with a string (no spaces) followed by a colon (and a blank character?) then the string is the scripting language: I didn't check the impact on existing scripts but it should be easy to write a reg exp to find all of them (I expect that the number will be small) and modify them to be compatible with the convention. I intentionally didn't focus on this second step.
>>
>> Jacopo
>>
>> On Mar 4, 2012, at 10:27 PM, Jacques Le Roux wrote:
>>
>>> I must says I only cursorily reviewed the code Jacopo committed and did not look into JSR-223 details.
>>> So I thought at some point you have to check which language wich is used?
>>>
>>> Like in
>>> + if ("groovy".equals(language)) {
>>> + if (scriptClass == null) {
>>> + scriptClass = ScriptUtil.parseScript(language, script);
>>> + }
>>> + if (scriptClass != null) {
>>> + result = InvokerHelper.createScript(scriptClass, GroovyUtil.getBinding(inputMap)).run();
>>> + }
>>> + } else if ("bsh".equals(language)) {
>>> + result = BshUtil.eval(script, UtilMisc.makeMapWritable(inputMap));
>>> + }
>>>
>>> In other words from Jacopo's code here, it seems you have to differentiate how scritps are parsed?
>>>
>>> Jacques
>>>
>>> From: "Adrian Crum"<ad...@sandglass-software.com>
>>>> Groovy supports JSR-223, so there is no reason to treat it differently. My question has nothing to do with which scripting engine
>>>> is supplied with OFBiz.
>>>>
>>>> -Adrian
>>>>
>>>> On 3/4/2012 8:43 PM, Jacques Le Roux wrote:
>>>>> I don't want to interfer with Jacopo's answer, but I guess it's because Groovy will be implemented OOTB. The others could be but
>>>>> Groovy is already part of the framework (the inital subject from Erwan was to completely remove BeanShell OOTB usage), I mean
>>>>> it's the idea and what Jacopo said already.
>>>>>
>>>>> I second this idea. Everybody can use her/his preferred scripting language in custom projects. But using only one language OOTB
>>>>> seems to be common sense. We chose groovy...
>>>>>
>>>>> Jacques
>>>>>
>>>>> From: "Adrian Crum"<ad...@sandglass-software.com>
>>>>>> The code changes tested fine.
>>>>>>
>>>>>> I noticed in your code comments that Groovy should be handled independently from other scripting languages. Why do you think
>>>>>> that?
>>>>>>
>>>>>> -Adrian
>>>>>>
>>>>>>
>>>>>> On 3/4/2012 7:27 AM, Jacopo Cappellato wrote:
>>>>>>> My changes are in commit 1296762
>>>>>>>
>>>>>>> Help with reviews and tests will be very much appreciated.
>>>>>>>
>>>>>>> Jacopo
>>>>>>>
>>>>>>> On Mar 3, 2012, at 1:45 PM, Jacopo Cappellato wrote:
>>>>>>>
>>>>>>>> On Mar 1, 2012, at 10:51 AM, Adrian Crum wrote:
>>>>>>>>
>>>>>>>>> As far as I know, most scripting engines have some sort of embedded cache. The problem will be that we can't clear the
>>>>>>>>> embedded
>>>>>>>>> cache like we can with our own cache implementation. I don't see that as a show stopper - it's mostly inconvenient.
>>>>>>>>>
>>>>>>>>> I can help out with the conversion. I don't think the task will be that hard.
>>>>>>>> Adrian, FYI I am enhancing some of the existing framework code that uses the GroovyUtil class to simplify this task.
>>>>>>>> I will commit my code changes today.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> Jacopo
>>>>>>>>
>>>>>>>>
>>>>>>>>