ht prefer a different language. For example, Jython and Ruby
have sizable communities.
My motivation in in implementing JSR-223 is the same as my motivation to
implement internationalization/globalization years ago - to open up the project
to more users.
So, let's try to keep the b
I finished my work on this integration in rev 1299924. We now have a
basic scripting framework that developers can extend by adding scripting
language engines. The framework includes a script helper class that is
based on Jacopo's DSL idea. Scripts can access the helper class using
the "ofbiz"
Since the "context" binding (variable) is used only in scripts run from
screen widgets, I was thinking we could rename it "widget" - which has
the added benefit of making operations on it more meaningful.
To summarize: service and event scripts return values via the "results"
binding, and scre
ying support for Java classes.
>>> It was my hope that we could come up with a Java-based script helper class
>>> that can be used by a variety of scripting languages that can access Java
>>> objects.
>>>
>>> I understand that there is
example, Jython and Ruby
have sizable communities.
My motivation in in implementing JSR-223 is the same as my motivation to
implement internationalization/globalization years ago - to open up the project
to more users.
So, let's try to keep the big picture in mind. If we come up with a scr
iety of scripting languages that can access Java objects.
>
> I understand that there is an interest in Groovy in this community, but other
> communities might prefer a different language. For example, Jython and Ruby
> have sizable communities.
>
> My motivation in in impl
languages that
can access Java objects.
I understand that there is an interest in Groovy in this community, but
other communities might prefer a different language. For example, Jython
and Ruby have sizable communities.
My motivation in in implementing JSR-223 is the same as my motivation to
The EntityConditionBuilder class I wrote a while back is a good example of a
groovy specific utility class, it takes advantage of groovy's language syntax
features and couldn't be used in any other scripting language (well, not in the
intended manner anyway).
A possible solution could be to hav
I was thinking of using _context. I know we try to stay away from
leading underscores as a general practice, but in this case I thought it
would make the replacement (and learning curve) easier.
-Adrian
On 3/6/2012 8:57 AM, Jacopo Cappellato wrote:
I would be in favor of bulk renaming all the
I would be in favor of bulk renaming all the "context" variables in our
scripts... maybe we could wait after the creation of the 12.04 release
branch... but I would be in favor even if we do this earlier.
Jacopo
On Mar 6, 2012, at 9:47 AM, Adrian Crum wrote:
> Update: I added a generic ScriptE
Update: I added a generic ScriptEngine to the service engine in rev 1297323.
I haven't updated screen widgets and mini-lang to use JSR-223 because
there is a compatibility problem. In JSR-223, the "context" binding is
reserved for the ScriptContext object, so any script code that uses the
vari
This could work but I was thinking to something more like having some "core"
packages (like entity and service) always imported in groovy scripts/services;
or having the "delegator" and "dispatcher" objects properly casted to their
interfaces (to take advantage of IDE autocompletion features); e
From: "Nicolas Malin"
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
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"
Because the value
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 attribu
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 perspect
From: "Adrian Crum"
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
expre
If you don't mind, I would like to get all of the issues resolved during
the design phase.
I will wait for the private email to understand what you mean by a
"secure" scripting package.
What I was suggesting is a script utility object that can be put in the
context so that all scripting lang
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
On Mar 5, 2012, at 8:46 AM, Adrian Crum wrote:
> It seems to me if there is a security issue using Groovy, then there would be
> an issue using any scripting language.
Yes, but what we would bundle ootb would be a secured packaged ready to run
Groovy scripts in a "secure" way and already packa
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
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_her
It seems to me if there is a security issue using Groovy, then there
would be an issue using any scripting language.
Why can't we put the "friendly methods" in the context, so all scripting
languages can use them?
-Adrian
On 3/5/2012 6:46 AM, Jacopo Cappellato wrote:
On Mar 4, 2012, at 9:16
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 "movin
On Mar 4, 2012, at 9:16 PM, Adrian Crum wrote:
> 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?
First of all, I apologize for having added my personal opinion to those
comme
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-2
No, the whole idea is to delegate that decision making to the
javax.script package.
-Adrian
On 3/4/2012 9: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 lan
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
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
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 alread
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 m
31 matches
Mail list logo
