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