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" <jacopo.cappell...@hotwaxmedia.com>
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
