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
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
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
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
Implementing JSR-223 should be rather easy but if I am not wrong it would
prevent the ability to cache the scripts (task that is currently done in
org.ofbiz.base.util.GroovyUtil, that is using the the more flexible
GroovyClassLoader mechanism); we could probably use the javax.script.Compilable
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 document is interesting and I agree with the approach in general.
I don't agree, but this is a small detail, with the assertion that currency
should be part of a framework: I can think of several applications not dealing
with money :-)
And if we want to design a framework for ERP
I included currency in the framework because i18n libraries the
framework is based on will include it.
A framework for ERP applications would be built on the framework I
proposed - I mentioned that in the document. In my mind, things should
be modular, instead of the monolithic design we have
On Mar 1, 2012, at 11:39 AM, Adrian Crum wrote:
I understand the workflow you are suggesting - cut down the size of the
existing framework and then switch to something else. In an ideal world we
could do that. Unfortunately, we have a lot of committers who believe more is
better, so while
Le 12/02/2012 20:43, Adrian Crum a écrit :
It would be nice if we could come up with a way to use JSR 223 in screen
widgets and mini-language.
Adrian,
would this mean that we'll be moving from
groovy.lang.Script
to
ScriptEngineManager and ScriptEngine ?
Do you think this would be a big task
2012/2/12 Adrian Crum adrian.c...@sandglass-software.com:
It would be nice if we could come up with a way to use JSR 223 in screen
widgets and mini-language.
-Adrian
Excellent idea ! I've starting reading the specs, and it seems to be
very interesting.
Some links:
*
It would be nice if we could come up with a way to use JSR 223 in screen
widgets and mini-language.
-Adrian
On 2/9/2012 6:31 AM, Jacques Le Roux wrote:
After almost 4 years, I can see no problems with that
Jacques
From: Erwan de FERRIERES erwan.deferrie...@gmail.com
Hi all,
in may 2008, we
Hi all,
in may 2008, we decided to move from beanshell to groovy
(http://ofbiz.markmail.org/message/5p33dhfnuh7gnfby?q=groovy+beanshell#query:groovy%20beanshell).
Since this time a lot of migration has been done, but still some
snippets are remaining in the code (mostly in screens).
What do you
Hi all,
Reading thru the mail archive and seeing the vote result there needn't be a
new voting round. But an umbrella JIRA with underlying issues and perhaps a
new branch to work on.
I would love to see it propositioned for an upcoming release.
Regards,
Pierre Smits
2012/2/8 Erwan de
2012/2/8 Pierre Smits pierre.sm...@gmail.com:
Hi all,
Reading thru the mail archive and seeing the vote result there needn't be a
new voting round. But an umbrella JIRA with underlying issues and perhaps a
new branch to work on.
I would love to see it propositioned for an upcoming release.
After almost 4 years, I can see no problems with that
Jacques
From: Erwan de FERRIERES erwan.deferrie...@gmail.com
Hi all,
in may 2008, we decided to move from beanshell to groovy
(http://ofbiz.markmail.org/message/5p33dhfnuh7gnfby?q=groovy+beanshell#query:groovy%20beanshell).
Since this
21 matches
Mail list logo
