A) I would like to see removed all the attributes "map-name" and just leave the "field" attribute; for example:
<clear-field field="foo" map-name="parameters"/> can be: <clear-field field="parameters.foo"/> B) instead of: <fail-property resource="ErrorMessages" property="FooError" /> we could have <fail-property property="ErrorMessages.FooError" /> C) instead of: <request-to-field> <session-to-field> we could have: <set field="foo" from="parameters.request.inputFoo"/> <set field="foo" from="parameters.session.inputFoo"/> D) similarly deprecate (replaced by "set"): <field-to-env> <field-to-field> <field-to-list> <field-to-request> <field-to-session> <property-to-field> <now-timestamp-to-env> <now-date-to-env> <map-to-map> <list-to-list> <string-to-field> <string-to-list> <to-string> <webapp-property-to-field> <set-current-user-login> I don't have more time today but there may be others :-) Jacopo On Mar 8, 2012, at 3:16 PM, Nicolas Malin wrote: > Ok thanks adrian > > Nicolas > Le 08/03/2012 14:46, [email protected] a écrit : >> Voting on each item will not work because there are too many. We can discuss >> things here and when there seems to be general agreement, I will ask for a >> vote on the entire grammar. When that vote passes, I will include the >> proposals in the grammar (move them out of the blue boxes and into the >> normal text), and change the status from draft to final. >> >> -Adrian >> >> Quoting Nicolas Malin <[email protected]>: >> >>> Thanks adrian for this works, >>> >>> I will add my propositions. >>> >>> After all proposition will include on wiki, how to you proceed to approve >>> each ? A vote on mailing list for each ? >>> >>> Nicolas >>> >>> Le 07/03/2012 19:18, Adrian Crum a écrit : >>>> I created a Wiki page to help get things started: >>>> >>>> https://cwiki.apache.org/confluence/display/OFBADMIN/Mini-language+Reference >>>> I put just enough information in it to work on the layout. I will >>>> continue working on it when I have time. Everyone with write access is >>>> welcome to work on it also. The information is based on the mini-language >>>> Java code - which is the ultimate authority. The schemas are inaccurate - >>>> they should be used only for looking up schema-supplied default values. >>>> >>>> The goal is to document the current mini-language grammar, and add >>>> proposed changes. If a proposal is approved, then it can get a green check >>>> mark. If a proposal is vetoed, then it can get a red X. When everyone >>>> agrees on the grammar, the document will be updated, and it will move out >>>> of the draft stage. Then the job will be to work on the Java and XML code >>>> to make it match the grammar. >>>> >>>> I put a couple of proposals in the page to help get things started. >>>> >>>> Let me know what you think. >>>> >>>> -Adrian >>>> >>>> On 3/6/2012 9:42 AM, Adrian Crum wrote: >>>>> <set field="field4" from="parameters.inputField1 + 10"/> <!-- use >>>>> Minilang built-in and efficient support: not currently supported but >>>>> maybe something to consider in the future --> >>>>> >>>>> The from attribute contains a UEL expression, so it is currently >>>>> supported. >>>>> >>>>> -Adrian >>>>> >>>>> On 3/6/2012 9:33 AM, Jacopo Cappellato wrote: >>>>>> On Mar 6, 2012, at 10:03 AM, 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. >>>>>> Ok, makes perfect sense, thank you. >>>>>> >>>>>>> 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. >>>>>> +1: by the way we could still use the "from" attribute for both: >>>>>> >>>>>> <set field="field4" from="parameters.inputField1"/> <!-- use Minilang >>>>>> built-in and efficient support --> >>>>>> <set field="field4" from="parameters.inputField1 + 10"/> <!-- use >>>>>> Minilang built-in and efficient support: not currently supported but >>>>>> maybe something to consider in the future --> >>>>>> <set field="field4" from="groovy: parameters.inputField1 + 10"/> <!-- >>>>>> use Groovy (inefficient) --> >>>>>> >>>>>> Jacopo >>>>>> >>>>>>> >>>>>>> -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 >>>>>>>>>>>>> >>> >>> >>> -- >>> Nicolas MALIN >>> Consultant >>> Tél : 06.17.66.40.06 >>> Site projet : http://www.neogia.org/ >>> ------- >>> Société LibrenBerry >>> Tél : 02.48.02.56.12 >>> Site : http://www.librenberry.net/ >>> >>> >> >> > > > -- > Nicolas MALIN > Consultant > Tél : 06.17.66.40.06 > Site projet : http://www.neogia.org/ > ------- > Société LibrenBerry > Tél : 02.48.02.56.12 > Site : http://www.librenberry.net/ >
