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 <jacopo.cappell...@hotwaxmedia.com>: > 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 >> <jacopo.cappell...@hotwaxmedia.com>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: (03) 9585 6788 >> Fax: (03) 9585 1086 >> Web: http://www.cohsoft.com.au/ >> Email: sa...@cohsoft.com.au >> >> 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
