It would be interesting to see the performance impact of that approach.
I overhauled Mini-language recently and in the process I made sure the
execution path was as short and straight as possible. That effort
produced a 40% performance improvement. I wonder how Java's
compile-time linking compares with Groovy's time spent in the
reflection API.
I agree it would be wonderful to have screen widgets inherit
Mini-language in their <action> elements.
-Adrian
Quoting "David E. Jones" <d...@me.com>:
One of my top annoyances with OFBiz coding is the inconsistency of
tools, especially the scripts and expressions within widgets and
simple-methods.
A first step would be to make all expressions, conditions, etc use
Groovy instead of JUEL and the bits of BeanShell that are still
used. Groovy has a lot of convenient stuff that JUEL and BeanShell
do not, and when coding I find it takes so much more work to
understand and work with the differences and the more cumbersome
syntax that I (and I've noticed many others) hacking around this
limitation with the ${groovy: ...} expressions, which are fine but
then have type conversion issues as this is really a string
expansion syntax. The whole FlexibleStringExpander could just call
into Groovy for evaluation instead of the various things plus
calling into JUEL that it currently does.
A bigger step would be to change the simple-method processing to be
just a FTL template that creates a Groovy script from the XML, and
then compile/cache/run the Groovy script. This has the added
benefits of dramatically simplifying the framework code (no need for
a Java class for each XML element), and makes it easy to do inline
Groovy scripts in simple-methods.
With either approach it would be nice to make the simple-method and
screen/form/etc actions blocks use the same XSD and be processed the
same way for better consistency (fewer surprises during dev and
testing, more general flexibility too).
As I do development with both Moqui and OFBiz I find this to be one
of the biggest differences that makes working with Moqui Framework
faster and less frustrating than with OFBiz. There are many
differences between the two frameworks, but this one stands out to
me as perhaps the most significant when working day-to-day, and
should be one of the easier ones to incorporate. Most existing
expressions written for JUEL should evaluate fine in Groovy, but
some would have to change... that would be the biggest impact of
this change on existing code.
-David
On Dec 31, 2013, at 4:55 AM, Adrian Crum
<adrian.c...@sandglass-software.com> wrote:
Maybe we can use the start of the new year as an opportunity to
consider the future of OFBiz and update our road map:
https://cwiki.apache.org/confluence/display/OFBADMIN/New+Features+Roadmap+-+Living+Document
--
Adrian Crum
Sandglass Software
www.sandglass-software.com
