Hi David, it is really interesting discussion. I understand the advantage of inlining service implementation in service definition; however I think that we could achieve a similar goal by implementing the service with a Groovy method and by defining some mechanism to declare in/out parameters and other service attributes near the Groovy method. For example we could have a layout like this:
some-component/servicedef/services.xml --------> service definitions with external implementation (see GroovyServices.groovy) some-component/servicedef/GroovySimpleServices.xml --------> service and service definitions some-component/scripts/GroovyServices.groovy --------> service implementations for services defined in services.xml In this way we will have the chance to use two mechanisms with the same language. For screen/form widgets we may consider similar approaches i.e. instead of a screen definition in xml with inlined forms/html/data preparation scripts as xml-actions we could use a template with inlined Groovy scripts; or a Groovy builder that builds a complex screen definition. But all the above ideas may not make much sense or may need to be refined a lot... the main concept is that, when we want to simplify (i.e. have in the same place the definition and implementation of an artifact) then we could skip the xml part and simply provide the implementation in Freemarker/Groovy rather than having an xml-action implementation inlined with the xml definition Jacopo On Mar 16, 2012, at 12:49 AM, David E Jones wrote: > > This is an interesting point. I thought about it a lot for Moqui and > ended up doing much more simple XML Actions, though actually enhancing > the entity find operations, and changed them to match the API better > (and handle things like the current find services do so that those > services aren't needed). > > The reason for getting rid of lots of stuff but enhancing things like > the entity find operations was because the main value I see for this is > quick/easy embedded data preparation in screens, and in Moqui service > implementations that are inline in the service definition (ie so you > don't need a separate file for the implementation of the service). > > In other words, it's nice to have something that is easy to use inside > the many existing XML files, and something like the simple-method fits > the bill well. > > What really bothers me with the simple-method stuff in OFBiz whenever I > use it is the inconsistency between the simple-method, screen actions, > form actions, etc, and the inconsistent handling of expressions and such > for field, from-field, value, etc attributes. Having everything use the > same XSD and having everything actually be a groovy expression (since it > is just transformed into a groovy script) made it much easier and less > frustrating to use. > > With it that was instead of how simple-methods currently are, I find the > xml actions to be quite convenient, and when they aren't I just inline > some groovy, or call out to another file if it's big enough (but nice to > be able to easily inline it to avoid working across multiple files... > something that you have to do a lot in OFBiz and it's really annoying). > > -David > > > Jacopo Cappellato wrote: >> 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 >>>>>>>>>> >>
