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