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/
