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