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" <adrian.c...@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" <adrian.c...@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
>>>>>>
>>>>>>
>>>>>>
