https://cwiki.apache.org/confluence/display/OFBTECH/Unified+Expression+Language+%28JSR-245%29+in+OFBiz
I don't know if there is a UEL editor with auto-completion. I don't know
if it would work if you found one, since you are editing XML, not UEL.
-Adrian
On 3/15/2012 2:36 PM, Nicolas Malin wrote:
others suggestions :
* deprecate find-by-primary-key and find-by-and, use entity-one and
entity-and instead.
* field-map inherits from set attribute (except field-name)
* change make-next-seq-id.seq-field-name by
make-next-seq-id.seq-field (for coherence)
* add filter-list-by-condition element
* add sub-element condition-expr-mapping with operator, join to run
an auto-mapping between entity and context:
EX1 :
<entity-condition entity-name="Person">
<condition-expr-mapping operator="contains" combine="or">
<exclude field-name="description"/>
</condition-expr-mapping>
</entity-condition>
EX2 :
<entity-condition entity-name="PartyPersonView">
<condition-list combine="and">
<condition-expr-mapping/>
<condition-expr field-name="statusId" value="PARTY_ENABLED"/>
</condition-list>
</entity-condition>
Just an ask on UEL,is there a completion to help young developer ?
With mini-lang element, it' really help full when your ide list
explicit element (as first-list-to-field
) I do not challenge UEL, I was just asking what it will be as
flexible daily.
I continue my reflexion on mini-lang
Nicolas
Le 06/03/2012 10:03, Nicolas Malin a écrit :
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
