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