Discussion: Mini-language Overhaul

[Adrian Crum-3]

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

[Anil Patel-3]

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
>

[byersa]

I think having a scripting language that can be expressed in markup
and managed via an xsd schema is a powerful feature. I would hate to
see it go away.

-Al

On Mon, Mar 5, 2012 at 12:46 PM, Anil Patel <[hidden email]> 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
>>
>

[byersa]

And by "go away", I mean "not get enhanced".
-Heinz

On Mon, Mar 5, 2012 at 12:53 PM, Al Byers <[hidden email]> wrote:

> I think having a scripting language that can be expressed in markup
> and managed via an xsd schema is a powerful feature. I would hate to
> see it go away.
>
> -Al
>
> On Mon, Mar 5, 2012 at 12:46 PM, Anil Patel <[hidden email]> 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]

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]

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

[Jacques Le Roux]

I don't currently use minilang because of the restrictions of the project I'm working on. But I'm also a fan. It's so much easier as
long as you don't get into too much complicated things. And contrary as it's often said, not that hard to learn.

Brainstorming later...

Jacques

From: "Jacopo Cappellato" <[hidden email]>

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

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.

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


Then we can remove script support from expressions, which will eliminate
ugly hacks like:

<set field="field4" value="${groovy: parameters.inputField1 + 10}"/>


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

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]

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]

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]

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

[Adrian Crum-3]

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

[Adrian Crum-3]

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

[Mansour]

Not sure if this discussion open for users as well.

I don't use mini-lang, and prefer to do things in java. But I am
wondering why not move all the repetitive code to java (copying
fields). Those who prefer to use mini-lang can have an XSLT that will
produce the java code as they want. This way, every contributor can
customize their XSLT and have their grammar that will produce the java
code. Maintenance will not be possible with mini-lang, since the code
generated is committed to SVN is in java.




On Wed, Mar 7, 2012 at 1:18 PM, Adrian Crum
<[hidden email]> wrote:

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

[Adrian Crum-3]

That's one of the advantages to mini-language - you don't need to
compile it. It would be nice to have a tool that converts schemas to
Java model classes however.

-Adrian

On 3/7/2012 11:35 PM, Mansour Al Akeel wrote:

> Not sure if this discussion open for users as well.
>
> I don't use mini-lang, and prefer to do things in java. But I am
> wondering why not move all the repetitive code to java (copying
> fields). Those who prefer to use mini-lang can have an XSLT that will
> produce the java code as they want. This way, every contributor can
> customize their XSLT and have their grammar that will produce the java
> code. Maintenance will not be possible with mini-lang, since the code
> generated is committed to SVN is in java.
>
>
>
>
> On Wed, Mar 7, 2012 at 1:18 PM, Adrian Crum
> <[hidden email]>  wrote:
>> 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
>>>>>>>>>>>

[Mansour]

Adrian,
what is your plan ? you want to use mini-lang for development and
compile to java at the same time ?!
Issues with recompile can resolved with an ant task that monitors src
directory for changes, and trigger a recompile when changes occur.
Reloading the compile java can be by external utilities. Honestly, I
don't think this is should be done by the framework, as it makes it
harder to maintain.

Tools that can reload java classes like jrebel (commercial), hotswap,
jreloader ... etc.



On Wed, Mar 7, 2012 at 11:22 PM, Adrian Crum
<[hidden email]> wrote:

> That's one of the advantages to mini-language - you don't need to compile
> it. It would be nice to have a tool that converts schemas to Java model
> classes however.
>
> -Adrian
>
>
> On 3/7/2012 11:35 PM, Mansour Al Akeel wrote:
>>
>> Not sure if this discussion open for users as well.
>>
>> I don't use mini-lang, and prefer to do things in java. But I am
>> wondering why not move all the repetitive code to java (copying
>> fields). Those who prefer to use mini-lang can have an XSLT that will
>> produce the java code as they want. This way, every contributor can
>> customize their XSLT and have their grammar that will produce the java
>> code. Maintenance will not be possible with mini-lang, since the code
>> generated is committed to SVN is in java.
>>
>>
>>
>>
>> On Wed, Mar 7, 2012 at 1:18 PM, Adrian Crum
>> <[hidden email]>  wrote:
>>>
>>> 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]

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/

[Adrian Crum-3]

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

[Malin Nicolas]

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/