Discussion: Mini-language Overhaul

[Jacopo Cappellato-4]

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, [hidden email] 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 <[hidden email]>:
>>
>>> 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 : [phone]
>>> Site projet : http://www.neogia.org/
>>> -------
>>> Société LibrenBerry
>>> Tél : [phone]
>>> Site : http://www.librenberry.net/
>>>
>>>
>>
>>
>
>
> --
> Nicolas MALIN
> Consultant
> Tél : [phone]
> Site projet : http://www.neogia.org/
> -------
> Société LibrenBerry
> Tél : [phone]
> Site : http://www.librenberry.net/
>

[Jacopo Cappellato-4]

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, [hidden email] 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 <[hidden email]>:
>>>
>>>> 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 : [phone]
>>>> Site projet : http://www.neogia.org/
>>>> -------
>>>> Société LibrenBerry
>>>> Tél : [phone]
>>>> Site : http://www.librenberry.net/
>>>>
>>>>
>>>
>>>
>>
>>
>> --
>> Nicolas MALIN
>> Consultant
>> Tél : [phone]
>> Site projet : http://www.neogia.org/
>> -------
>> Société LibrenBerry
>> Tél : [phone]
>> Site : http://www.librenberry.net/
>>
>

[Adrian Crum-3]

This is a good list. Thanks Jacopo!

There are some issues with your suggestions - comments inline...

-Adrian

On 3/8/2012 3: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" />

Keep in mind that UEL would interpret FooError as an element of a Map
called ErrorMessages.

What you suggested can be done, but it will require more modifications
to the UEL integration - something I try to avoid because it causes more
problems than it solves. I recommend we keep the resource attribute.

>
> 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"/>

That can be done, but with a slight difference:

<set field="foo" from="request.parameters.inputFoo"/>
<set field="foo" from="session.parameters.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>

We can eliminate <now-timestamp-to-env> if we just put a nowTimestamp
field in the method context - like we do now with screen widgets.

> <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 agree all of those can be deprecated.

> 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, [hidden email] 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<[hidden email]>:
>>>
>>>> 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 : [phone]
>>>> Site projet : http://www.neogia.org/
>>>> -------
>>>> Société LibrenBerry
>>>> Tél : [phone]
>>>> Site : http://www.librenberry.net/
>>>>
>>>>
>>>
>>
>> --
>> Nicolas MALIN
>> Consultant
>> Tél : [phone]
>> Site projet : http://www.neogia.org/
>> -------
>> Société LibrenBerry
>> Tél : [phone]
>> Site : http://www.librenberry.net/
>>

[Jacopo Cappellato-4]

On Mar 8, 2012, at 7:03 PM, Adrian Crum wrote:

>>
>> B) instead of:
>>
>> <fail-property resource="ErrorMessages" property="FooError" />
>>
>> we could have
>>
>> <fail-property property="ErrorMessages.FooError" />
>
> Keep in mind that UEL would interpret FooError as an element of a Map called ErrorMessages.
>
> What you suggested can be done, but it will require more modifications to the UEL integration - something I try to avoid because it causes more problems than it solves. I recommend we keep the resource attribute.

Np then, I was not even sure it was a good idea and if requires customizations to uel then I agree it is not worth the effort.

Thank you,

Jacopo

[Adrian Crum-3]

Some more food for thought...

Looking through the Java code, I can see that there is no runtime
validation being performed. Granted, a decent XML editor will warn you
about required attributes and elements and such, but not everyone uses
that type of XML editor. Worse yet, there is no way to know you've done
something wrong - because mini-lang hides the errors in verbose log
statements. So, I would like to add runtime validation. If the script is
coded improperly, then it should throw an exception.

Another change I would like to make is to remove default attribute
values in the schema. From my perspective, defaults should be in the
mini-language code. The wiki page has demonstrated to me how difficult
it is to understand what's going on when you have to look through Java
code, and then also look through the schema to see what values it is
supplying. Plus, it makes me wonder how mini-language will behave when
the server doesn't have access to the schema.

Which brings up another point: Once the grammar has been cleaned up, we
will need a new schema. I think we need to start giving our schemas
version numbers so that XML editors and runtime XML validation will work
properly.

-Adrian


On 3/8/2012 6:19 PM, Jacopo Cappellato wrote:

> On Mar 8, 2012, at 7:03 PM, Adrian Crum wrote:
>
>>> B) instead of:
>>>
>>> <fail-property resource="ErrorMessages" property="FooError" />
>>>
>>> we could have
>>>
>>> <fail-property property="ErrorMessages.FooError" />
>> Keep in mind that UEL would interpret FooError as an element of a Map called ErrorMessages.
>>
>> What you suggested can be done, but it will require more modifications to the UEL integration - something I try to avoid because it causes more problems than it solves. I recommend we keep the resource attribute.
> Np then, I was not even sure it was a good idea and if requires customizations to uel then I agree it is not worth the effort.
>
> Thank you,
>
> Jacopo

[Jacques Le Roux]

From: "Adrian Crum" <[hidden email]>
> Some more food for thought...
>
> Looking through the Java code, I can see that there is no runtime validation being performed. Granted, a decent XML editor will
> warn you about required attributes and elements and such, but not everyone uses that type of XML editor. Worse yet, there is no
> way to know you've done something wrong - because mini-lang hides the errors in verbose log statements. So, I would like to add
> runtime validation. If the script is coded improperly, then it should throw an exception.

+1

No time for the rest for now, Jacopo's proposition sounds good to me

Jacques

> Another change I would like to make is to remove default attribute values in the schema. From my perspective, defaults should be
> in the mini-language code. The wiki page has demonstrated to me how difficult it is to understand what's going on when you have to
> look through Java code, and then also look through the schema to see what values it is supplying. Plus, it makes me wonder how
> mini-language will behave when the server doesn't have access to the schema.
>
> Which brings up another point: Once the grammar has been cleaned up, we will need a new schema. I think we need to start giving
> our schemas version numbers so that XML editors and runtime XML validation will work properly.
>
> -Adrian
>
>
> On 3/8/2012 6:19 PM, Jacopo Cappellato wrote:
>> On Mar 8, 2012, at 7:03 PM, Adrian Crum wrote:
>>
>>>> B) instead of:
>>>>
>>>> <fail-property resource="ErrorMessages" property="FooError" />
>>>>
>>>> we could have
>>>>
>>>> <fail-property property="ErrorMessages.FooError" />
>>> Keep in mind that UEL would interpret FooError as an element of a Map called ErrorMessages.
>>>
>>> What you suggested can be done, but it will require more modifications to the UEL integration - something I try to avoid because
>>> it causes more problems than it solves. I recommend we keep the resource attribute.
>> Np then, I was not even sure it was a good idea and if requires customizations to uel then I agree it is not worth the effort.
>>
>> Thank you,
>>
>> Jacopo

[David E. Jones-2]

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
>>>>>>>

[Jacopo Cappellato-4]

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
>>>>>>>>

[Adrian Crum-3]

Something like that (FTL-based converter) would be useful for a tool to
batch convert mini-language to Groovy. From my perspective, such a tool
would need to be in place before we can seriously consider changing over
to Groovy. Interest in mini-language may be diminishing, but there is
still a mountain of code written in it. Converting all of it by hand
would be nearly impossible.

-Adrian

On 3/15/2012 6:02 AM, 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
>>>>>>>>>

[Malin Nicolas]

Hi Adrian,

I tried to edit the Mini-language+Reference page to adding my comment on
entity-condition, but how to edit it ?
This page is in OFBiz Admin space on confluence and I have not edit
access on this space, maybe you want that only commiter and PMC edit the
draft ?

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 : [phone]
Site projet : http://www.neogia.org/
-------
Société LibrenBerry
Tél : [phone]
Site : http://www.librenberry.net/

[Adrian Crum-3]

Yes, edit access is restricted to committers.

Comments on the draft should be posted here. I want to make sure the
discussion stays on the mailing list so everyone can participate.

-Adrian

On 3/15/2012 12:42 PM, Nicolas Malin wrote:

> Hi Adrian,
>
> I tried to edit the Mini-language+Reference page to adding my comment
> on entity-condition, but how to edit it ?
> This page is in OFBiz Admin space on confluence and I have not edit
> access on this space, maybe you want that only commiter and PMC edit
> the draft ?
>
> 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
>>>>>>>>>>>
>
>

[Malin Nicolas]

Ok, It's clear, the sentence "This is a draft document. It can be
modified at any time by anyone." is disturbing in this case.
Maybe change it by "This is a draft document. Send your comments on dev
mailing" ?

Nicolas

Le 15/03/2012 14:02, Adrian Crum a écrit :

> Yes, edit access is restricted to committers.
>
> Comments on the draft should be posted here. I want to make sure the
> discussion stays on the mailing list so everyone can participate.
>
> -Adrian
>
> On 3/15/2012 12:42 PM, Nicolas Malin wrote:
>> Hi Adrian,
>>
>> I tried to edit the Mini-language+Reference page to adding my comment
>> on entity-condition, but how to edit it ?
>> This page is in OFBiz Admin space on confluence and I have not edit
>> access on this space, maybe you want that only commiter and PMC edit
>> the draft ?
>>
>> 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 : [phone]
Site projet : http://www.neogia.org/
-------
Société LibrenBerry
Tél : [phone]
Site : http://www.librenberry.net/

[Adrian Crum-3]

Done. Thank you for the suggestion!

-Adrian

On 3/15/2012 1:15 PM, Nicolas Malin wrote:

> Ok, It's clear, the sentence "This is a draft document. It can be
> modified at any time by anyone." is disturbing in this case.
> Maybe change it by "This is a draft document. Send your comments on
> dev mailing" ?
>
> Nicolas
>
> Le 15/03/2012 14:02, Adrian Crum a écrit :
>> Yes, edit access is restricted to committers.
>>
>> Comments on the draft should be posted here. I want to make sure the
>> discussion stays on the mailing list so everyone can participate.
>>
>> -Adrian
>>
>> On 3/15/2012 12:42 PM, Nicolas Malin wrote:
>>> Hi Adrian,
>>>
>>> I tried to edit the Mini-language+Reference page to adding my
>>> comment on entity-condition, but how to edit it ?
>>> This page is in OFBiz Admin space on confluence and I have not edit
>>> access on this space, maybe you want that only commiter and PMC edit
>>> the draft ?
>>>
>>> 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
>>>>>>>>>>>>>
>>>
>>>
>
>

[Malin Nicolas]

others suggestions :
  * deprecate find-by-primary-key and find-by-and, use entity-one and
entity-and instead.
  * field-map inherits from set attribute (except field-name)
  * change make-next-seq-id.seq-field-name by make-next-seq-id.seq-field
(for coherence)
  * add filter-list-by-condition element
  * add sub-element condition-expr-mapping with operator, join to run an
auto-mapping between entity and context:
  EX1 :
<entity-condition entity-name="Person">
<condition-expr-mapping operator="contains" combine="or">
<exclude field-name="description"/>
</condition-expr-mapping>
</entity-condition>

  EX2 :
<entity-condition entity-name="PartyPersonView">
<condition-list combine="and">
<condition-expr-mapping/>
<condition-expr field-name="statusId" value="PARTY_ENABLED"/>
</condition-list>
</entity-condition>

Just an ask on UEL,is there a completion to help young developer ? With
mini-lang element, it' really help full when your ide list explicit
element (as first-list-to-field
) I do not challenge UEL, I was just asking what it will be as flexible
daily.

I continue my reflexion on mini-lang
Nicolas

Le 06/03/2012 10:03, Nicolas Malin a écrit :

> I'm a mini-lang supporter too :)
>
> At the begin I used java code generation for service but with the time
> I found mini-lang more effective and simple to maintain.
> On mini-lang review, I propose to unify attribute name that have same
> purpose.
>   ex : <set field="field1" ...
>         while
> <entity-and ...
> <field-map field-name="field1"
>
> On improvement, on the great <entity-condition> element,
> filter-by-date attribute give the possibility to filter by
> nowTimestamp on fromDate/thruDate. If you want filter on a specific
> date orother fromDate/thruDatefield, we need recreate the condition.
> To simplify, instead of an attribute it would add an element
> condition-date
>
> <entity-condition list="myEntites" entity-name="Entity">
> <condition-date from="myDateField" field-from="fromDate"
> field-thru="thruDate" ignore="" />
> By default from="now", field-from="fromDate", field-thru="thruDate",
> ignore search the showHistory field (pratical to implement a generic
> history search for form)
> Finally : <entity-condition list="myEntites" entity-name="Entity"
> filter-by-date="true"/> == entity-condition list="myEntites"
> entity-name="Entity"/><condition-date/>
>
> for brainstorm
>> ========================
>> <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...)
> Why not call just Number instead of BigDecimal ?
>> * 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
> Interesting attribute, I'm always a little afraidby automatic
> conversion if element is not on the good type.
> I prefer to push the type :
> <set field="field2" from="parameters.inputField1 +
> parameters.inputField2" type="BigDecimal"/>
> <set field="field2" from="parameters.inputField1 +
> parameters.inputField2" type="String"/>
>> 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 : [phone]
Site projet : http://www.neogia.org/
-------
Société LibrenBerry
Tél : [phone]
Site : http://www.librenberry.net/

[Adrian Crum-3]

https://cwiki.apache.org/confluence/display/OFBTECH/Unified+Expression+Language+%28JSR-245%29+in+OFBiz

I don't know if there is a UEL editor with auto-completion. I don't know
if it would work if you found one, since you are editing XML, not UEL.

-Adrian

On 3/15/2012 2:36 PM, Nicolas Malin wrote:

> others suggestions :
>  * deprecate find-by-primary-key and find-by-and, use entity-one and
> entity-and instead.
>  * field-map inherits from set attribute (except field-name)
>  * change make-next-seq-id.seq-field-name by
> make-next-seq-id.seq-field (for coherence)
>  * add filter-list-by-condition element
>  * add sub-element condition-expr-mapping with operator, join to run
> an auto-mapping between entity and context:
>  EX1 :
> <entity-condition entity-name="Person">
> <condition-expr-mapping operator="contains" combine="or">
> <exclude field-name="description"/>
> </condition-expr-mapping>
> </entity-condition>
>
>  EX2 :
> <entity-condition entity-name="PartyPersonView">
> <condition-list combine="and">
> <condition-expr-mapping/>
> <condition-expr field-name="statusId" value="PARTY_ENABLED"/>
> </condition-list>
> </entity-condition>
>
> Just an ask on UEL,is there a completion to help young developer ?
> With mini-lang element, it' really help full when your ide list
> explicit element (as first-list-to-field
> ) I do not challenge UEL, I was just asking what it will be as
> flexible daily.
>
> I continue my reflexion on mini-lang
> Nicolas
>
> Le 06/03/2012 10:03, Nicolas Malin a écrit :
>> I'm a mini-lang supporter too :)
>>
>> At the begin I used java code generation for service but with the
>> time I found mini-lang more effective and simple to maintain.
>> On mini-lang review, I propose to unify attribute name that have same
>> purpose.
>>   ex : <set field="field1" ...
>>         while
>> <entity-and ...
>> <field-map field-name="field1"
>>
>> On improvement, on the great <entity-condition> element,
>> filter-by-date attribute give the possibility to filter by
>> nowTimestamp on fromDate/thruDate. If you want filter on a specific
>> date orother fromDate/thruDatefield, we need recreate the condition.
>> To simplify, instead of an attribute it would add an element
>> condition-date
>>
>> <entity-condition list="myEntites" entity-name="Entity">
>> <condition-date from="myDateField" field-from="fromDate"
>> field-thru="thruDate" ignore="" />
>> By default from="now", field-from="fromDate", field-thru="thruDate",
>> ignore search the showHistory field (pratical to implement a generic
>> history search for form)
>> Finally : <entity-condition list="myEntites" entity-name="Entity"
>> filter-by-date="true"/> == entity-condition list="myEntites"
>> entity-name="Entity"/><condition-date/>
>>
>> for brainstorm
>>> ========================
>>> <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...)
>> Why not call just Number instead of BigDecimal ?
>>> * 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
>> Interesting attribute, I'm always a little afraidby automatic
>> conversion if element is not on the good type.
>> I prefer to push the type :
>> <set field="field2" from="parameters.inputField1 +
>> parameters.inputField2" type="BigDecimal"/>
>> <set field="field2" from="parameters.inputField1 +
>> parameters.inputField2" type="String"/>
>>> 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
>>>>>>
>>
>>
>
>

[Jacques Le Roux]

From: "Nicolas Malin" <[hidden email]>
> Just an ask on UEL,is there a completion to help young developer ? With mini-lang element, it' really help full when your ide list
> explicit element (as first-list-to-field
> ) I do not challenge UEL, I was just asking what it will be as flexible daily.

I have not much time at the moment and hardly follow the threads
But yes this is an important point Nicolas, thank you to mention it!

Jacques

> I continue my reflexion on mini-lang
> Nicolas

[David E. Jones-2]

Some editors, like IntelliJ IDEA, do actually support scripts embedded
in other files. I use this quite a bit for groovy scripts embedded in
XML... but it doesn't work so well for groovy expressions because it
only works when you define object types for variables and such.

-David


Adrian Crum wrote:

> https://cwiki.apache.org/confluence/display/OFBTECH/Unified+Expression+Language+%28JSR-245%29+in+OFBiz
>
>
> I don't know if there is a UEL editor with auto-completion. I don't know
> if it would work if you found one, since you are editing XML, not UEL.
>
> -Adrian
>
> On 3/15/2012 2:36 PM, Nicolas Malin wrote:
>> others suggestions :
>>  * deprecate find-by-primary-key and find-by-and, use entity-one and
>> entity-and instead.
>>  * field-map inherits from set attribute (except field-name)
>>  * change make-next-seq-id.seq-field-name by
>> make-next-seq-id.seq-field (for coherence)
>>  * add filter-list-by-condition element
>>  * add sub-element condition-expr-mapping with operator, join to run
>> an auto-mapping between entity and context:
>>  EX1 :
>> <entity-condition entity-name="Person">
>> <condition-expr-mapping operator="contains" combine="or">
>> <exclude field-name="description"/>
>> </condition-expr-mapping>
>> </entity-condition>
>>
>>  EX2 :
>> <entity-condition entity-name="PartyPersonView">
>> <condition-list combine="and">
>> <condition-expr-mapping/>
>> <condition-expr field-name="statusId" value="PARTY_ENABLED"/>
>> </condition-list>
>> </entity-condition>
>>
>> Just an ask on UEL,is there a completion to help young developer ?
>> With mini-lang element, it' really help full when your ide list
>> explicit element (as first-list-to-field
>> ) I do not challenge UEL, I was just asking what it will be as
>> flexible daily.
>>
>> I continue my reflexion on mini-lang
>> Nicolas
>>
>> Le 06/03/2012 10:03, Nicolas Malin a écrit :
>>> I'm a mini-lang supporter too :)
>>>
>>> At the begin I used java code generation for service but with the
>>> time I found mini-lang more effective and simple to maintain.
>>> On mini-lang review, I propose to unify attribute name that have same
>>> purpose.
>>>   ex : <set field="field1" ...
>>>         while
>>> <entity-and ...
>>> <field-map field-name="field1"
>>>
>>> On improvement, on the great <entity-condition> element,
>>> filter-by-date attribute give the possibility to filter by
>>> nowTimestamp on fromDate/thruDate. If you want filter on a specific
>>> date orother fromDate/thruDatefield, we need recreate the condition.
>>> To simplify, instead of an attribute it would add an element
>>> condition-date
>>>
>>> <entity-condition list="myEntites" entity-name="Entity">
>>> <condition-date from="myDateField" field-from="fromDate"
>>> field-thru="thruDate" ignore="" />
>>> By default from="now", field-from="fromDate", field-thru="thruDate",
>>> ignore search the showHistory field (pratical to implement a generic
>>> history search for form)
>>> Finally : <entity-condition list="myEntites" entity-name="Entity"
>>> filter-by-date="true"/> == entity-condition list="myEntites"
>>> entity-name="Entity"/><condition-date/>
>>>
>>> for brainstorm
>>>> ========================
>>>> <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...)
>>> Why not call just Number instead of BigDecimal ?
>>>> * 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
>>> Interesting attribute, I'm always a little afraidby automatic
>>> conversion if element is not on the good type.
>>> I prefer to push the type :
>>> <set field="field2" from="parameters.inputField1 +
>>> parameters.inputField2" type="BigDecimal"/>
>>> <set field="field2" from="parameters.inputField1 +
>>> parameters.inputField2" type="String"/>
>>>> 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
>>>>>>>
>>>
>>>
>>
>>

[David E. Jones-2]

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
>>>>>>>>>
>

[Jacopo Cappellato-4]

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
>>>>>>>>>>
>>

[Adrian Crum-3]

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.
>>

One of the reasons for the overhaul is to fix some of those
inconsistencies, and to improve data-type handling.

In my review of the mini-language code, I see two main problems:

1. The original mini-language treated everything as Strings. This causes
a multitude of problems because of all the String-to-SomeClass and
SomeClass-to-String conversions. The overhaul will fix that.
2. There is no syntax checking. No exceptions are thrown when invalid
XML is encountered during parsing, and any invalid syntax encountered
during runtime is hidden in verbose log messages. So, there is no way
for the developer to know they have done something wrong.

On top of the implementation problems, there are documentation problems.
The schemas are incorrect, and information on mini-language behavior is
scattered across a number of wiki pages. The overhaul will fix that by
creating an authoritative mini-language reference page, update the code
to follow that reference, and then update the schemas to match the code
and reference.

https://cwiki.apache.org/confluence/display/OFBADMIN/Mini-language+Reference

-Adrian