Groovy services and a DSL for OFBiz - a POC

[Jacopo Cappellato-4]

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

[Karl Pitrich]

Hi Jacopo,

a nice step in the right direction, IMHO. I like it.

Do you think it's possible to hack up a transpiler from Minilang to JacopoLang(tm),
(i.e. like Coffescript has for Javascript), so that we can get rid of minilang entirely?


Greetings,

 - Karl

On 08.03.2012, at 19:02, 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

[Erwan de FERRIERES]

Le 08/03/2012 20:04, Karl Pitrich a écrit :
> Hi Jacopo,
>
> a nice step in the right direction, IMHO. I like it.
>
> Do you think it's possible to hack up a transpiler from Minilang to JacopoLang(tm),
> (i.e. like Coffescript has for Javascript), so that we can get rid of minilang entirely?

Hi Karl,

minilang won't be removed from OFBiz. It is widely used, and very
useful. Look at the other thread Adrian started, there is a will to
improve it !

Cheers,

>
>
> Greetings,
>
>   - Karl
>
> On 08.03.2012, at 19:02, 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
>
>

--
Erwan de FERRIERES
www.nereide.biz

[Jacques Le Roux]

Hi Jacopo,

Interesting, but then (question to all, and espaically Adrian who began on minilang overhaul ) should we continue the minilang
overhaul or rather gather all efforts to completly, step by step, move all minilang scripts to this new possiblity?

Jacques

From: "Jacopo Cappellato" <[hidden email]>

> 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

[Adrian Crum-3]

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.

-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

[Jacopo Cappellato-4]

Thanks Jacques.

I actually don't know the answer but I will be surprised if everyone will agree to switch from Minilang to Groovy (at least not in the short term); by the way I still see a value in the effort of cleaning and making Minilang more consistent (maybe I would not spend much of my time on the effort, because at the moment I see a greater potential in Groovy, but I understand that it makes sense to invest time in that great language); even if at some point in the future we will decide to migrate out of Minilang, having a cleaner set of scripts will greatly help the migration.

Jacopo

On Mar 8, 2012, at 8:29 PM, Jacques Le Roux wrote:

> Hi Jacopo,
>
> Interesting, but then (question to all, and espaically Adrian who began on minilang overhaul ) should we continue the minilang overhaul or rather gather all efforts to completly, step by step, move all minilang scripts to this new possiblity?
>
> Jacques
>
> From: "Jacopo Cappellato" <[hidden email]>
>> 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

[Jacopo Cappellato-4]

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

[Anne Jessel]

Hi Jacopo

That is an excellent start! I used to prefer minilang to java because it
was so easy to do common tasks, but 2 things about it were so annoying that
I now only use it for the simplest tasks. But with java I have to put up
with all that extra code to get simple things done.

Your groovy approach takes the best of minilang and the best of java, and
combines them. My only concern with it is speed, but I suppose we could use
ant to compile the groovy if there is a problem?

A couple of thoughts (probably you have already thought of these):

Change runService to runServiceSync, so there can also be a runServiceAsync.

The design effort on this could combine with the current design effort on
improving minilang. Adrian's new wiki page (
https://cwiki.apache.org/confluence/display/OFBADMIN/Mini-language+Reference)
could be used to guide what functionality the new groovy DSL needs. So
there could (almost) be a one-to-one mapping between a minilang tag and a
DSL function.

Do you intend for the DSL to work with events, as well as services?

Cheers,
Anne.

On 9 March 2012 05:02, Jacopo Cappellato
<[hidden email]>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

--
Coherent Software Australia Pty Ltd
PO Box 2773
Cheltenham Vic 3192
Phone: [phone]
Fax: [phone]
Web: http://www.cohsoft.com.au/
Email: [hidden email]

Bonsai ERP, the all-inclusive ERP system
http://www.bonsaierp.com.au/

[Jacopo Cappellato-4]

Thank you Anne,

please see my comments inline:

On Mar 9, 2012, at 1:55 AM, Anne wrote:

> Hi Jacopo
>
> That is an excellent start! I used to prefer minilang to java because it
> was so easy to do common tasks, but 2 things about it were so annoying that
> I now only use it for the simplest tasks. But with java I have to put up
> with all that extra code to get simple things done.
>
> Your groovy approach takes the best of minilang and the best of java, and
> combines them. My only concern with it is speed, but I suppose we could use
> ant to compile the groovy if there is a problem?

It would be really nice to run some serious test on performance and compare the two tools.
Currently the bytecode generated parsing Groovy is cached by OFBiz; but speed is one aspect and we should also consider the usage of memory.

>
> A couple of thoughts (probably you have already thought of these):
>
> Change runService to runServiceSync, so there can also be a runServiceAsync.

Yes, this is a nice to have; I would prefer a slightly different naming like:

runService: sync calls
scheduleService or submitService or runServiceAsync: async calls

In this way we still have a very easy name, runService, for the most common usage (calling services synchronously)

>
> The design effort on this could combine with the current design effort on
> improving minilang. Adrian's new wiki page (
> https://cwiki.apache.org/confluence/display/OFBADMIN/Mini-language+Reference)
> could be used to guide what functionality the new groovy DSL needs. So
> there could (almost) be a one-to-one mapping between a minilang tag and a
> DSL function.

That page (and effort) will be really useful to help this DSL grow in the right direction; but in general Minilang, and most of all the huge amount of Minilang code we have in OFBiz (some good, some bad) is really useful to decide what we need in a Groovy DSL: in fact all the ideas I have tried to implement in this poc are based on a careful review of Minilang (and my experience of Minilang development).
I like the idea of preparing a page that shows the best practices for implementing Minilang-equivalent code in Groovy: however, rather that implementing a one-to-one method mapping between Minilang and this DSL I would prefer to stay focused on the most common tasks only: all the other operations can still be used using the standard support provided by delegator, dispatcher etc... objects, or the various utils classes we have in OFBiz.
A natural and good way to decide what we should provide as a DSL and what (probably) not is how frequent the feature is currently used in our Minilang code (but of course feedback from developers using it would help greatly).
For example:
the "call-service" operation in Minilang can take an optional attribute "require-new-transaction": if it is set to true the service will be executed in a separate transaction.
the equivalent Groovy (DSL for OFBiz) is "runService" and doesn't support this option (it runs the service in the same transaction); even if it would be trivial to enhance the DSL to support also a runService method that takes an additional argument (or use a different name), after reviewing the existing code I realized that we won't probably need this feature: in all the OFBiz "applications" the require-new-transaction attribute is set to "true" for only 2 service calls; and for this rare occasions you can achieve the same in Groovy using the dispatcher:

result1 = runService('someService', inputMap); // run the service in the current transaction
result2 = dispatcher.runSync('someService', inputMap, 36000, true); // run in a new transaction
if (ServiceUtil.isError(result)) return error(ServiceUtil.getErrorMessage(result));

Of course we will have the flexibility to expand at will our DSL.
Another nice feature is that it is possible to extend the DSL base class and add additional custom methods: everyone could customize the DSL and possibly implement an industry specific (or company specific or project specific) DSL very easily (something currently rather difficult in Minilang).

>
> Do you intend for the DSL to work with events, as well as services?

Thanks for asking: yes my next task in my todo list is to enable it for events and data preparation scripts.

Cheers,

Jacopo

>
> Cheers,
> Anne.
>
> On 9 March 2012 05:02, Jacopo Cappellato
> <[hidden email]>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
>
>
>
>
> --
> Coherent Software Australia Pty Ltd
> PO Box 2773
> Cheltenham Vic 3192
> Phone: [phone]
> Fax: [phone]
> Web: http://www.cohsoft.com.au/
> Email: [hidden email]
>
> Bonsai ERP, the all-inclusive ERP system
> http://www.bonsaierp.com.au/

[Sascha Rodekamp-3]

Hi Jacopo,
great job! Groovy as DSL is very handsome (cause i can use a debugger :-)).

In the longterm future i would support Adrians approach to create an
abstract implementation of the DSL.

Some words to the groovy speed. In (theoretically) benchmarks groovy
is slower than java. Interesting would be a comparison between
mini-lang and groovy. I think the Groovy performance  will be
absolutely sufficient because of the easy integration with Java. If
something’s too slow, I do it in Java. More important using the DSL is
the maintainability, developer productivity and the tool support.

Have a good day
Sascha

2012/3/9 Jacopo Cappellato <[hidden email]>:

> Thank you Anne,
>
> please see my comments inline:
>
> On Mar 9, 2012, at 1:55 AM, Anne wrote:
>
>> Hi Jacopo
>>
>> That is an excellent start! I used to prefer minilang to java because it
>> was so easy to do common tasks, but 2 things about it were so annoying that
>> I now only use it for the simplest tasks. But with java I have to put up
>> with all that extra code to get simple things done.
>>
>> Your groovy approach takes the best of minilang and the best of java, and
>> combines them. My only concern with it is speed, but I suppose we could use
>> ant to compile the groovy if there is a problem?
>
> It would be really nice to run some serious test on performance and compare the two tools.
> Currently the bytecode generated parsing Groovy is cached by OFBiz; but speed is one aspect and we should also consider the usage of memory.
>
>>
>> A couple of thoughts (probably you have already thought of these):
>>
>> Change runService to runServiceSync, so there can also be a runServiceAsync.
>
> Yes, this is a nice to have; I would prefer a slightly different naming like:
>
> runService: sync calls
> scheduleService or submitService or runServiceAsync: async calls
>
> In this way we still have a very easy name, runService, for the most common usage (calling services synchronously)
>
>>
>> The design effort on this could combine with the current design effort on
>> improving minilang. Adrian's new wiki page (
>> https://cwiki.apache.org/confluence/display/OFBADMIN/Mini-language+Reference)
>> could be used to guide what functionality the new groovy DSL needs. So
>> there could (almost) be a one-to-one mapping between a minilang tag and a
>> DSL function.
>
> That page (and effort) will be really useful to help this DSL grow in the right direction; but in general Minilang, and most of all the huge amount of Minilang code we have in OFBiz (some good, some bad) is really useful to decide what we need in a Groovy DSL: in fact all the ideas I have tried to implement in this poc are based on a careful review of Minilang (and my experience of Minilang development).
> I like the idea of preparing a page that shows the best practices for implementing Minilang-equivalent code in Groovy: however, rather that implementing a one-to-one method mapping between Minilang and this DSL I would prefer to stay focused on the most common tasks only: all the other operations can still be used using the standard support provided by delegator, dispatcher etc... objects, or the various utils classes we have in OFBiz.
> A natural and good way to decide what we should provide as a DSL and what (probably) not is how frequent the feature is currently used in our Minilang code (but of course feedback from developers using it would help greatly).
> For example:
> the "call-service" operation in Minilang can take an optional attribute "require-new-transaction": if it is set to true the service will be executed in a separate transaction.
> the equivalent Groovy (DSL for OFBiz) is "runService" and doesn't support this option (it runs the service in the same transaction); even if it would be trivial to enhance the DSL to support also a runService method that takes an additional argument (or use a different name), after reviewing the existing code I realized that we won't probably need this feature: in all the OFBiz "applications" the require-new-transaction attribute is set to "true" for only 2 service calls; and for this rare occasions you can achieve the same in Groovy using the dispatcher:
>
> result1 = runService('someService', inputMap); // run the service in the current transaction
> result2 = dispatcher.runSync('someService', inputMap, 36000, true); // run in a new transaction
> if (ServiceUtil.isError(result)) return error(ServiceUtil.getErrorMessage(result));
>
> Of course we will have the flexibility to expand at will our DSL.
> Another nice feature is that it is possible to extend the DSL base class and add additional custom methods: everyone could customize the DSL and possibly implement an industry specific (or company specific or project specific) DSL very easily (something currently rather difficult in Minilang).
>
>>
>> Do you intend for the DSL to work with events, as well as services?
>
> Thanks for asking: yes my next task in my todo list is to enable it for events and data preparation scripts.
>
> Cheers,
>
> Jacopo
>
>>
>> Cheers,
>> Anne.
>>
>> On 9 March 2012 05:02, Jacopo Cappellato
>> <[hidden email]>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
>>
>>
>>
>>
>> --
>> Coherent Software Australia Pty Ltd
>> PO Box 2773
>> Cheltenham Vic 3192
>> Phone: [phone]
>> Fax: [phone]
>> Web: http://www.cohsoft.com.au/
>> Email: [hidden email]
>>
>> Bonsai ERP, the all-inclusive ERP system
>> http://www.bonsaierp.com.au/
>

--

Sascha Rodekamp
    Visit the new german OFBiz Blog: http://www.ofbiz.biz
    Lynx-Consulting GmbH
    Johanniskirchplatz 6
    D-33615 Bielefeld
    http://www.lynx.de

[Jacopo Cappellato-4]

On Mar 9, 2012, at 8:37 AM, Sascha Rodekamp wrote:

> In the longterm future i would support Adrians approach to create an
> abstract implementation of the DSL.

This would be great even in a shorter term future.
I would suggest that we keep our DSL as simple and as clean possible: I am actually already forcing myself in these terms:
* I do not add a DSL method because I think it may be useful; I have to prove that it is (by reviewing current usage and frequency in Minilang equivalent)
* before adding a new DSL method I write a few services without it and when I identify a good recurring pattern I add it in my todo list of something that could become a method
* when I implement the method, I keep it as simple as possible without adding additional stuff (arguments etc...) that is not proven to be useful
* I expect that the final set of DSL method will be very small (not much bigger that it is now) and with very simple arguments
* we should always use standard API for anything less common more complex: this is an advantage we have in groovy (over Minilang)

In this way this Groovy specific DSL will not grow in complexity (at the end we will have very few lines of code) but it will be extensively tested over real world scenarios (e.g. converting some of the existing services); at that point it will be easy to convert the code to be used by all the scripting languages supporting JSR-223. And even if that would be impossible it would still be easy to create a different class for JSR-223 languages; then in ofbiz we could keep 2 service engines:

* "ofbizgroovy": this is the current "groovy" service engine that makes use of the DSL implemented by the class we have now (GroovyBaseScript)
* "script": this is the engine capable of running a service implemented on any scripting language supporting JSR-223 (including Groovy); this engine could inject a different "generic" version of DSL (e.g. GenericBaseScript or similar)

(of course this would only make sense if a Groovy specific DSL provides some specific advantage to Groovy services over the generic one).
In this way OFBiz will support virtually any language with a nice DSL support or Groovy with a special DSL support; this would still make a lot of sense because the code required to maintain a groovy specific engine (the one right now) is very small (a few lines of code).

Jacopo

[Adrian Crum-3]

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.

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);
}

-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

[Jacopo Cappellato-4]

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

[Adrian Crum-3]

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

[Jacopo Cappellato-4]

> On Mar 9, 2012, at 10:03 AM, Adrian Crum wrote:
>> Another advantage of this approach is the syntax remains the same across languages.

I also have some doubts that a language independent DSL would be very useful: the main concept is to extend the language of your preference in a tr

For example, in order to copy contents of maps from map to map in Groovy you can do something like:

lookupFieldMap = parameters.subMap(['inventoryItemId', 'productId'])

so for Groovy a utility method to transfer items from map to map would not be needed; but in another (less powerful) language it may be useful to have. Since we do not know what language the user will choose, it would be difficult to predict the useful methods in our DSL... and we may end up implementing a new language that is "language independent"; I want to avoid this and simply add the minimal amount of code to complete a specific language very powerful for what we need in OFBiz applications.
A (super lightweight) DSL, specific to the language chosen by the community for the OFBiz applications, is the best choice in my opinion.

Jacopo

[Adrian Crum-3]

On 3/9/2012 11:30 AM, Jacopo Cappellato wrote:
>> On Mar 9, 2012, at 10:03 AM, Adrian Crum wrote:
>>> Another advantage of this approach is the syntax remains the same across languages.
> I also have some doubts that a language independent DSL would be very useful: the main concept is to extend the language of your preference in a tr
>
> For example, in order to copy contents of maps from map to map in Groovy you can do something like:
>
> lookupFieldMap = parameters.subMap(['inventoryItemId', 'productId'])

Now I understand the confusion - there is nothing "DSL" about copying a
Map. In my mind the "Domain" in an OFBiz DSL is "OFBiz" - so the DSL
adds OFBiz-specific extensions to the language.

What you're describing would be handled by third-party libraries.

-Adrian

[Jacopo Cappellato-4]

On Mar 9, 2012, at 12:28 PM, Adrian Crum wrote:

> 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?

Adrian, no there is nothing wrong but I think we are not understanding each other's vision and goal.
I see the work I am doing like a small "plugin" to add to Groovy a few things to make it a perfect language for OFBiz applications (like Minilang). This is similar to the concept of creating some custom freemarker transforms to simplify the creation of pages.
So to me the logical step is:
1) select the language that is closest to what we need (or create one, like Minilang)
2) add to it what is missing (this is my small DSL)
3) then use it
The effort I am doing is to see if Groovy + a small DSL can be a valid choice for the future of OFBiz. When this effort is done, if you (or anyone else) will see a potential to reuse the same DSL for other scripting languages, I would be more than happy to see it converted in a language independent way (this would be a trivial effort).

What (I think) you are proposing is:
1) make OFBiz framework independent from any specific scripting language (apart from Java)
2) implement a DSL to write OFBiz applications in Java as a series of method calls to an helper class
3) the user will then chose the scripting language of his preference and then will use the DSL to write code

What I don't see in your plan is what we want to do with the existing "applications" code and new code that will come: continue with Minilang, switch to Groovy, use a mix of languages?
If my interpretation of your vision is correct, I have also some doubts about #2: the risk is that we implement a big api to do everything we think a potential user of an unknown language would need; the risk is that we loose the advantages of each specific language.

Jacopo

[Adrian Crum-3]

On 3/9/2012 11:48 AM, Jacopo Cappellato wrote:

> On Mar 9, 2012, at 12:28 PM, Adrian Crum wrote:
>
>> 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?
> Adrian, no there is nothing wrong but I think we are not understanding each other's vision and goal.
> I see the work I am doing like a small "plugin" to add to Groovy a few things to make it a perfect language for OFBiz applications (like Minilang). This is similar to the concept of creating some custom freemarker transforms to simplify the creation of pages.
> So to me the logical step is:
> 1) select the language that is closest to what we need (or create one, like Minilang)
> 2) add to it what is missing (this is my small DSL)
> 3) then use it
> The effort I am doing is to see if Groovy + a small DSL can be a valid choice for the future of OFBiz. When this effort is done, if you (or anyone else) will see a potential to reuse the same DSL for other scripting languages, I would be more than happy to see it converted in a language independent way (this would be a trivial effort).
>
> What (I think) you are proposing is:
> 1) make OFBiz framework independent from any specific scripting language (apart from Java)

Exactly.

> 2) implement a DSL to write OFBiz applications in Java as a series of method calls to an helper class

No, provide a helper class that developers can use to implement a DSL.

> 3) the user will then chose the scripting language of his preference and then will use the DSL to write code

Yes, the developer can choose a scripting language. Whether or not the
scripting language has been extended to a DSL by incorporating the
helper class is a separate issue.

>
> What I don't see in your plan is what we want to do with the existing "applications" code and new code that will come: continue with Minilang, switch to Groovy, use a mix of languages?

Anything we want. As long as we keep it generic, we are free to
add/remove any scripting language. On the other hard, if we make it all
Groovy-centric, then we have a lot of re-engineering to do if we decide
to make a change.

> If my interpretation of your vision is correct, I have also some doubts about #2: the risk is that we implement a big api to do everything we think a potential user of an unknown language would need; the risk is that we loose the advantages of each specific language.

Again, I think there is some confusion on what a "DSL for OFBiz" means.
If it means we can add OFBiz-specific extensions to an existing
language, then the API can be kept simple.

-Adrian

[Jacopo Cappellato-4]

On Mar 9, 2012, at 12:59 PM, Adrian Crum wrote:

>>
>> What I don't see in your plan is what we want to do with the existing "applications" code and new code that will come: continue with Minilang, switch to Groovy, use a mix of languages?
>
> Anything we want. As long as we keep it generic, we are free to add/remove any scripting language. On the other hard, if we make it all Groovy-centric, then we have a lot of re-engineering to do if we decide to make a change.

I really don't see how using a Groovy specific DSL for OFBiz would make the system more Groovy-centric than using Groovy with a generic/general purpose helper class.

OFBiz (I mean the applications, not the framework) will become Groovy-centric if and when we will decide to use Groovy as the primary language to implement their services/events/scripts; that will be the big decision; the fact that all the Groovy services/events/scripts will mostly use a small DSL well suited to be integrated in Groovy to extend its language will actually make it easier for us to migrate out of Groovy:
1) convert the DSL class (100 lines of code?) into a generic helper class well suited for the new language (or discard it completely if the new language will come with the features we need ootb)
2) convert all the Groovy services/events/scripts to the new language

The big effort will be #2 and not #1 and we are now discussing about #1.

Jacopo

>
>> If my interpretation of your vision is correct, I have also some doubts about #2: the risk is that we implement a big api to do everything we think a potential user of an unknown language would need; the risk is that we loose the advantages of each specific language.
>
> Again, I think there is some confusion on what a "DSL for OFBiz" means. If it means we can add OFBiz-specific extensions to an existing language, then the API can be kept simple.
>
> -Adrian
>

[Jacopo Cappellato-4]

On Mar 9, 2012, at 12:36 PM, Adrian Crum wrote:

>
> On 3/9/2012 11:30 AM, Jacopo Cappellato wrote:
>>> On Mar 9, 2012, at 10:03 AM, Adrian Crum wrote:
>>>> Another advantage of this approach is the syntax remains the same across languages.
>> I also have some doubts that a language independent DSL would be very useful: the main concept is to extend the language of your preference in a tr
>>
>> For example, in order to copy contents of maps from map to map in Groovy you can do something like:
>>
>> lookupFieldMap = parameters.subMap(['inventoryItemId', 'productId'])
>
> Now I understand the confusion - there is nothing "DSL" about copying a Map. In my mind the "Domain" in an OFBiz DSL is "OFBiz" - so the DSL adds OFBiz-specific extensions to the language.
>
> What you're describing would be handled by third-party libraries.

I am simply saying that, if the goal is to be ready to switch from Groovy to the next language that will come, and we have code like this:

lookupFieldMap = parameters.subMap(['inventoryItemId', 'productId'])
record = findOne('InventoryItem', lookupFieldMap)

then the difficult part will be to convert the first line, not the second.
I don't see how the following code:

lookupFieldMap = parameters.subMap(['inventoryItemId', 'productId'])
record = script.findOne('InventoryItem', lookupFieldMap)

would make it easier.

Jacopo