Actually, it is impossible because a lot of framework code depends on
mini-language.
-Adrian
On 3/14/2012 8:49 AM, Jacopo Cappellato wrote:
This is nice.
It would be also nice to move Minilang framework code out of the OFBiz framework to
become a separate project for the language itself (and "OFBiz applications"
could use it as they use Groovy); but I know this will be impossible because of the
dependencies on OFBiz services/delegator.
Jacopo
On Mar 14, 2012, at 9:34 AM, Adrian Crum wrote:
Speaking of consolidation, once I have the mini-language grammar finalized, I
will have mini-language implement JSR-223 so that it can be run in the same
generic way. Then we will be able to remove a some of the mini-language
specific classes (service/event engines).
-Adrian
On 3/14/2012 8:29 AM, Jacopo Cappellato wrote:
On Mar 14, 2012, at 9:23 AM, Adrian Crum wrote:
On 3/14/2012 7:56 AM, Jacopo Cappellato wrote:
* after the switch to JSR-223 the "DSL method" are accessed thru the "ofbiz"
reference (instead of being directly available as method calls)
You could implement your own script engine factory to enable the extended
Script class + DSL idea (GroovyBaseScript).
Yes, this is what I meant... however I think it is fine to keep the "ofbiz."
syntax for now and see how it goes (the switch in the future would be a matter of a few
search-and-replace operations).
Actually a more compelling reason for using a custom engine would be to enable
debugging... but even if we decide to do this I would prefer to continue to use the
"ofbiz." syntax (i.e. do not inject the GroovyBaseScript)... in this way the
decision engine switch will not affect in any way the code in the scripts. When
everything will be consolidated it will be easier to see what the is the best way to go.
Jacopo
-Adrian
