Some editors, like IntelliJ IDEA, do actually support scripts embedded in other files. I use this quite a bit for groovy scripts embedded in XML... but it doesn't work so well for groovy expressions because it only works when you define object types for variables and such.
-David Adrian Crum wrote: > 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 >>>>>>> >>> >>> >> >>
