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"<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 >>>>>>>> >>>>>>>> >>>>>>>>