On May 19, 2008, at 10:07 AM, David E Jones wrote:
Thanks to some recent work from Joe Eckard OFBiz now has pretty good
support for the Groovy scripting language.
While this is kind of interesting on its own, what was really
interesting was to find out (after not looking at groovy for
probably about 4 years) that it supports nearly all of the Java
syntax, and in addition offers significant syntax sugar and
functionality, including the dot syntax we like in FTL and various
OFBiz XML elements/attributes (though it is way better than any of
those...).
The reason that point peaked my interest was because my main reason
for sticking with bsh as the scripting language for OFBiz was that
it follows the Java syntax and works with most JavaScript funny
business too, and thus reduces the learning curve for both back-end
and front-end developers.
The downsides to bsh are somewhat significant, starting with the
fact that it isn't so much a community driven project as it is one
man's pet project, and to that point hasn't had a release in years.
The functionality and performance of Beanshell also leaves a lot to
be desired, especially compared to what Groovy now offers.
In spite of the fact that Groovy has received so much attention in
the press and such in recent months (well, for over a year now), and
there are funny/cool things like "Groovy on Grails" that exist,
Groovy really is a good scripting language and has some impressive
features to help with development efficiency, and makes up for many
of the things that make Java and Beanshell cumbersome to use.
So, what I am proposing is that we change the best practice
recommended scripting language in OFBiz from Beanshell to Groovy.
This would mean eventually moving all .bsh files to .groovy files
(which is fortunately easy because most, if not all, of the OFBiz
bsh files will run as-is through groovy, though it would be good to
clean things up as we go...).
It would be great to see this migration implemented soon.
In my opinion, the priority could be this:
1) change the best practice recommendation
2) migrate (with minimal changes/work) all the existing .bsh scripts
to .groovy scripts
3) clean and improve the migrated scripts to take full advantage of
the new language
We could implement #1 and #2 very soon in one big batch, while #3
could be done over time (unless we can bulk change some of the code in
the scripts).
Jacopo
The point of this thread is to open up the topic for discussion
before doing anything like a vote.
So, please research, then comment!
-David
