Ah, and just to be clear: I also agree with the comments in Confluence about deprecating other elements as well (I actually didn't include them in my list but I agree they should be removed).
Jacopo On Mar 8, 2012, at 4:18 PM, Jacopo Cappellato wrote: > 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, adrian.c...@sandglass-software.com 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 <malin.nico...@librenberry.net>: >>> >>>> 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/ >> >
