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
