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"<[email protected]>
>>>> 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"<[email protected]>
>>>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>>
