Now that we have the basic framework working, we can explore this idea
further.
Right now we have ScriptHelper object available through the key ofbiz.
The object is retrieved from a single ScriptHelperFactory instance.
If we made the getInstance method of ScriptHelperFactory return a
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 screen
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
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
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 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
The EntityConditionBuilder class is a good example of how we can make
scripting more convenient.
Different scripting languages will have varying 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
I'm not sure I follow what you're saying. I'm sure a java based script helper
class in the context could be useful but I don't think it should preclude the
ability to include classes in the context that assist with language specific
features.
I don't really see how giving users the ability
Fair enough. Users of other scripting languages can adapt the code to
suit their language.
-Adrian
On 3/6/2012 11:49 PM, Scott Gray wrote:
I'm not sure I follow what you're saying. I'm sure a java based script helper
class in the context could be useful but I don't think it should preclude
Yes, I agree with the general strategy: OFBiz will be (or it is) flexible and
ready to be used with alternative tools; our effort as a community will be that
of opening it up and slimming it down instead of trying to include all the
possible alternative tools in our package; and the work that
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 packaged
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
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
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
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
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
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
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.
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); etc...
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
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 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 =
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
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
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
comments
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
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
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}
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
30 matches
Mail list logo
