Very interesting, thank you David. By the way, and slightly off topic, in the future of OFBiz I am having an hard time to find the real need for these Minilang/xml-actions: in my opinion Groovy supported by a simple DSL (or call it how you want) would cover all the needs (in screens, events, services etc...) with the same consistent language.
Jacopo On Mar 15, 2012, at 6:42 AM, David E Jones wrote: > > If you translate the entire simple-method into a groovy script (perhaps > using an FTL file) and then compile/cache/run that groovy script you can > avoid these overhead problems... and also trim the size of the code to > execute simple-methods by a LOT (ie all those Java objects per > simple-method operation would go away). > > As an example the template in Moqui that does just this is available here: > > https://github.com/jonesde/moqui/blob/master/framework/template/XmlActions.groovy.ftl > > One nice thing about this is that everything is groovy by default so you > can inline it anywhere. > > For debugging whenever there is an error just log the generated groovy > script (with lines numbers) along with the error message so you can > easily see where the problem happened and why. > > -David > > > Adrian Crum wrote: >> Replacing FSE with Groovy is a bad idea. Adam and I optimized FSE so >> that it is very lightweight and fast. I also optimized the UEL >> integration so there is very little overhead in the evaluation process. >> Switching everything to Groovy will slow things down and increase memory >> usage. Also keep in mind that Groovy creates a class for every script, >> so we will run out of permgen space again. >> >> I think a wiser strategy would be to make mini-lang as feature complete >> as possible, and include a from-script attribute for any feature gaps. >> In other words, use from-script as a last resort - because it is costly. >> >> -Adrian >> >> On 3/6/2012 8:53 AM, Jacopo Cappellato wrote: >>> On Mar 6, 2012, at 9:32 AM, Adrian Crum wrote: >>> >>>> I don't understand what you mean by supporting a limited number of >>>> types. Currently, mini-lang supports any type - thanks to the >>>> conversion framework. >>> The conversion framework is fine; I was thinking that we could >>> implicitly (by default) treat in Minilang all the numbers as >>> BigDecimals, all the strings as GStrings/Expandable Strings; where >>> special conversions are required than the type can be specified. >>> >>>> I like the idea of changing the from-field attribute to from. I would >>>> like to see a from-script attribute added: >>>> >>>> <set field="field4" from-script="groovy: parameters.inputField1 + >>>> 10"/><!-- Use Groovy --> >>>> >>> and why not: >>> >>> <set field="field4" from="parameters.inputField1"/><!-- Use Groovy >>> internally: refactor OFBiz custom code to delegate on Groovy the >>> evaluation of simple assignments; this could potentially replace >>> FlexibleStringExpander related code --> >>> <set field="field4" from="groovy: parameters.inputField1 + 10"/><!-- >>> Use Groovy explicitly to evaluate the expression (use the same "from" >>> attribute instead of a separate "from-script")--> >>> <set field="field4" from="parameters.inputField1 + 10"/><!-- Use >>> Groovy (by default, configurable) to evaluate the expression--> >>> <set field="field4" from="beanshell: parameters.inputField1 + >>> 10"/><!-- Use Beanshell to evaluate the expression--> >>> >>> ? >>> >>>> Then we can remove script support from expressions, which will >>>> eliminate ugly hacks like: >>>> >>>> <set field="field4" value="${groovy: parameters.inputField1 + 10}"/> >>>> >>> +1 >>> >>> Jacopo >>> >>>> -Adrian >>>> >>>> >>>> On 3/6/2012 7:31 AM, Jacopo Cappellato wrote: >>>>> I am a big fan of Minilang too. >>>>> The "evolution" strategy that I would like to see implemented for >>>>> Minilang is actually the same one I would liketo see applied to >>>>> OFBiz framework in general: review the current usage of the tool, >>>>> fix existing usage for consistency (upgrade old code to use newer >>>>> mechanisms offered by the tool), get rid of unused or old mechanisms >>>>> in the attempt to slim down the size of the framework code, >>>>> unify/simplify mechanisms based on lesson learned; all of this could >>>>> be useful even to prepare the future migration to a different tool >>>>> (e.g. Groovy). >>>>> >>>>> I know that it is very vague and doesn't add much to this thread but >>>>> I like the approach suggested by Adrian. >>>>> In my opinion, a good way to define a new version of the "set" >>>>> operation could be that of analyzing how we are currently using the >>>>> operation in OFBiz: as a starting point we could start by searching >>>>> all occurrences of "<set " string in OFBiz, then review them and see >>>>> different patterns; discuss and define the few ones that we like >>>>> more, convert all code to use them consistently, then (or in the >>>>> same phase) define the new element to better implement the patterns >>>>> that we like. >>>>> >>>>> And now I am switching to the "brainstorming" mode :-) >>>>> >>>>> Kind regards, >>>>> >>>>> Jacopo >>>>> >>>>> ======================== >>>>> <brainstorming> >>>>> I would like to have a "set" operation that implements some of the >>>>> ideas of the "configure by exception" concept. >>>>> As regards the type supported, but pending the review of existing >>>>> usage, we may consider to only support these: >>>>> >>>>> * Object >>>>> * List >>>>> * Map >>>>> * BigDecimal/BigInteger (all numbers in Minilang should be treated >>>>> as BigDecimal; no support for Integer, Float etc...) >>>>> * String (expander i.e. the equivalent of GString in Groovy) >>>>> * a date object >>>>> >>>>> Then we could get rid of the "from-field" attribute and replace it >>>>> with a "from" attribute that can take as input a single field (as it >>>>> is now) or an expression; some examples (all the following are >>>>> evaluated using Groovy except where a different language is >>>>> specified i.e. default scripting language): >>>>> >>>>> <set field="field1" from="parameters.inputField1"/> // field1 will >>>>> have the same type of inputField1 >>>>> <set field="field2" from="parameters.inputField1 + >>>>> parameters.inputField2"/> // if inputField1 and inputField2 are >>>>> numbers then field2 will be the BigDecimal sum of the two >>>>> <set field="field3" from="parameters.inputField1 * 10"/> >>>>> <set field="field4" from="script:bsh parameters.inputField1 + >>>>> 10"/> // use Beanshell >>>>> <set field="field5" from="parameters.inputField1" >>>>> type="BigDecimal"/> // if inputField1 is a string representation >>>>> of a number we can convert with the explicit definition of the type >>>>> >>>>> For the constant values (I am not sure if it is a good idea, but for >>>>> now I will throw it out): >>>>> >>>>> <set field="stringField" value="This is a string"/> >>>>> <set field="stringField" value="This is a string with a ${variable}"/> >>>>> // the following two are equivalent >>>>> <set field="bigDecimalField" value="100"/> // the system attempt >>>>> to parse "100" as a number first (BigDecimal) and then as a string >>>>> <set field="bigDecimalField" value="100" type="BigDecimal"/> >>>>> <set field="stringField" value="100" type="String"/> // treat the >>>>> field as a string >>>>> >>>>> </brainstorming> >>>>> On Mar 5, 2012, at 9:07 PM, Adrian Crum wrote: >>>>> >>>>>> I am not one of those people. I use mini-lang almost exclusively. >>>>>> >>>>>> -Adrian >>>>>> >>>>>> On 3/5/2012 7:46 PM, Anil Patel wrote: >>>>>>> Adrian, >>>>>>> Thanks for starting this thread. >>>>>>> >>>>>>> While we all love mini-lang, I am wondering if we should really >>>>>>> ask ourselves if we really want to overhaul mini-lang or should we >>>>>>> consider alternates. From what I know, Not many people like to >>>>>>> build application using mini lang. Many end up using Java or Groovy. >>>>>>> >>>>>>> Thanks and Regards >>>>>>> Anil Patel >>>>>>> HotWax Media Inc >>>>>>> >>>>>>> On Mar 5, 2012, at 9:47 AM, Adrian Crum wrote: >>>>>>> >>>>>>>> Mini-language has evolved a lot over the years. Most of the >>>>>>>> development has occurred on an as-needed basis, so there is no >>>>>>>> clear design or implementation - things just get tacked on over >>>>>>>> time. >>>>>>>> >>>>>>>> A recent discussion has opened up the possibility to rework the >>>>>>>> mini-language<set> element. From my perspective, that task is >>>>>>>> long overdue. >>>>>>>> >>>>>>>> Also, the schemas are out of date, and they are unnecessarily >>>>>>>> complicated. So, those need a thorough going over. >>>>>>>> >>>>>>>> While we are at it, why don't we create a draft design document >>>>>>>> based on the current implementation, and then use it to look for >>>>>>>> other ways mini-language can be improved? We can all offer >>>>>>>> suggestions and comments, agree on a final design, finalize the >>>>>>>> draft, and then implement it in code. The design document then >>>>>>>> becomes the developer's reference. >>>>>>>> >>>>>>>> What do you think? >>>>>>>> >>>>>>>> -Adrian >>>>>>>>
