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.
>
> 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; 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
