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" variable.
There is still some work left to do to complete this task - various bits
of framework code that invoke scripts need to use the new ScriptUtil
class instead of whatever they are using now. Also, the JavaDocs are
incomplete. I will leave those tasks for others to complete.
As I mentioned previously, there is a name clash with the "context"
variable that might cause problems. I added a "widget" variable to take
its place, so scripts that reference "context" need to be changed to
reference "widget" instead. By the way, BSH uses the "script" variable
name for its own helper class - that's why we use the "ofbiz" variable
name. I'm sure we will encounter other surprises as this is built out.
-Adrian
On 3/11/2012 4:32 PM, Adrian Crum wrote:
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 widget scripts return values via the
"widget" binding.
What do you think?
-Adrian
On 3/6/2012 9:17 AM, Adrian Crum wrote:
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 "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 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 variable "context" will be using the
ScriptContext object - not the context Map. I'm not sure how to
proceed from here.
-Adrian
On 3/6/2012 7:58 AM, Jacopo Cappellato wrote:
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...
But I don't have a clear list at the moment so please do not
consider my notes a blocker.
I am working at a POC for a "best practice" Groovy service
implementation and this should end up with a "wish list" of
features I would like to have. Then we can discuss the best way to
achieve this.
Jacopo
On Mar 5, 2012, at 9:14 AM, Adrian Crum wrote:
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 languages can use it.
Whatever methods you have in mind could be implemented in a
generic way and reused. Personally, I would like to use something
like:
// Groovy, JavaScript
partyValue = script.entityOne("Party");
if (partyValue)...
In other words, have an object in the context that gives us the
convenience of mini-language.
-Adrian
On 3/5/2012 8:01 AM, Jacopo Cappellato wrote:
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 with hundreds of scripts.
If the user will add a new jar to support a different script
(and the user will also have to implement the custom scripts)
then this will be less secure but there isn't much we could do
as we delegate to JSR-223 the implementation of security.
Why can't we put the "friendly methods" in the context, so all
scripting languages can use them?
I am not sure I understand what you are proposing (the method
would be language specific) but for now we can postpone this
discussion at when (if it will ever happen) we will discuss
about this approach.
Jacopo
-Adrian
On 3/5/2012 6:46 AM, Jacopo Cappellato wrote:
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 :-) but I thought that in this way it was
easier to exchange design ideas; the comments can actually be
removed.
The reasons I think we could treat Groovy in a special way
(but I don't have a strong opinion on this) are:
* ootb OFBiz will still be packaged with Groovy jars (they are
required by all the existing scripts and by some other code
like the implementation of "Groovy service engine" and "Groovy
event handler") and so the dependency on Groovy will still be
there even if we run it with JSR-223
* the code to run Groovy in the special way is now all
contained in the ScriptUtil class and there are actually a few
lines of code to maintain for it
* keeping a custom way for Groovy has two main advantages that
are not currently used but I would like to consider in the
short term (and I don't think they are supported thru
JSR-223... but I am not sure):
** security: I would like to restrict the JVM security
settings for dynamic Groovy snippets like ${groovy: ...}; I
have some concerns in this area that I will address in a
separate email soon; in this way we will "secure" the ootb
system (packaged with several groovy scripts and the groovy
jars) but of course if the user will add to it jars files for
a new scripting language (executed using JSR-223) then the
security issue will still be there, but at least the user will
know about it
** I would like to inject some OFBiz friendly methods to all
Groovy scripts, so that they can be used by Groovy scripts to
run services, use the delegator etc...
We should also consider the impact on performance, even if the
best way to go is probably to run some performance tests on
the system running Groovy with current code and with the
system running Groovy using a custom method and then compare
the results.
Jacopo
-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
