From: "Nicolas Malin" <malin.nico...@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" <adrian.c...@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"<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
--
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/