On 3/9/2012 10:55 AM, Jacopo Cappellato wrote:
On Mar 9, 2012, at 10:03 AM, Adrian Crum wrote:
I noticed how you set up the GroovyBaseScript class - so that the methods are
accessible as if they were a part of the script. That approach might cause
problems with name clash. I might write a method in my script that is the same
as a DSL method, and then I get odd behavior I can't explain until I look
through the DSL reference and discover a matching method name.
Your method would be used instead.
Exactly. You don't see a problem with that?
The approach I suggested earlier would solve that problem by putting the DSL
object in the script context (bindings). Instead of:
party = makeValue("Party");
use:
party = script.makeValue("Party");
Another advantage of this approach is the syntax remains the same across
languages. In JavaScript:
var party = script.makeValue("Party");
in Jython:
party = script.makeValue("Party");
etc...
If Groovy users REALLY REALLY want to make the DSL methods accessible as if
they were a part of the script, then we can have GroovyBaseScript implement the
DSL interface and delegate to the script object:
Map makeValue(String entityName) throws ExecutionServiceException {
return binding.getVariable('script').makeValue(entityName);
}
We can discuss how to extend the DSL to all the languages out there
I'm not suggesting that we extend the DSL for any language. I'm
suggesting the opposite - keep it generic so all languages can use it.
I'm having a hard time understanding the push back on this. All I'm
suggesting is that we make the DSL a Java interface/class instead of a
Groovy script so the DSL can be reused in other scripting languages. Is
there something fundamentally wrong with that idea that I'm not
understanding?
; for now I would still like to concentrate on this implementation that makes
use of Groovy; when the effort will be (mostly) finalized we will have a good
implementation of a DSL for OFBiz and it will be easy to extend it to be usable
by all scripts. But at the moment I would like to avoid to loose any of the
Groovy abilities just because I want to support all languages: at the moment it
is not a big decision because the specific framework code for Groovy will be
limited to a few lines; the big decision will be to choose the preferred set of
languages for the future of OFBiz... that will be the real dependency/decision
(even if we will invoke them in a language independent way); currently we have:
* Minilang and Java for services
* Groovy (and widgets) for data preparation scripts
In the future we may want to use Groovy also for the service part (I don't
know); at that point OFBiz will have a huge dependency on Groovy code (this is
already true for the data preparation) and maintaining one small Groovy
dependent class in the framework to make the services/data scripts more elegant
would not worry me at all (when the next language will be chosen we will of
course have to convert this small class and then the huge amount of services
and data scripts).
Jacopo
-Adrian
On 3/8/2012 9:56 PM, Jacopo Cappellato wrote:
On Mar 8, 2012, at 8:30 PM, Adrian Crum wrote:
I like the general concept, but I think it can be made generic so it is
reusable in other languages. That is what I was trying to describe earlier.
I looked at GroovyBaseScript and I don't see any reason why it needs to be made
Groovy-specific. Have the class access bindings from JSR-223 and Tah-dah! It
works for all scripting languages.
Thank you Adrian.
In this first step I was actually focused on the definition (and their design
as DSL) of all the implicit rules that make Minilang such a productive tool,
and I have used Groovy because it helps to implement this kind of patterns.
But if we can enhance and reuse the same class for all the JSR-223 compliant
scripting languages that would be nice.
Jacopo
-Adrian
On 3/8/2012 6:02 PM, Jacopo Cappellato wrote:
Hi all,
I have just completed my first pass in the implementation of a DSL (Domain
Specific Language) for OFBiz that can be used by Groovy services to act like a
modern version of Minilang.
Please review my notes here:
https://cwiki.apache.org/confluence/display/OFBIZ/Groovy+Services+and+DSL+for+OFBiz
I look forward to your comments and feedback but please consider that 1) it is
a work in progress, 2) I spent a lot of time and mental energy in the effort
(reaching simplicity is really complex task!)... so please don't be too picky
:-)
Regards,
Jacopo
PS: if you find it useful, I can commit the Groovy service mentioned in the
page in Confluence
