I completely agree that having *one* set on Minilang operations for all the actions (forms/screens/methods) is a good step forward. My only doubt is about the effort required for the migration: I see an opportunity to migrate all our applications code to Groovy instead; at that point all OFBiz code will be either Java or Groovy and Freemarker.
Jacopo On Apr 5, 2012, at 1:45 AM, Adrian Crum wrote: > If we can agree on the mini-language syntax and get a good implementation, > then the next step would be to integrate it with the screen widgets. > Personally, I have always wanted the screen widget <actions> element to > behave the same way as the mini-language <simple-method> element. That > concept can be extended further to have <simple-method> elements in the > screen widget files (https://issues.apache.org/jira/browse/OFBIZ-4090). > > -Adrian > > On 4/4/2012 6:41 PM, Jacques Le Roux wrote: >> Hi Adrian, >> >> This looks like a great step forward. I really wonder though if we will >> still have many possible syntaxes ("std minilang" (should not vary with the >> place it's used), bsh, grooy, uel, etc.) or if it will be more constrained >> >> I guess you will follow David's suggestion on this? >>> What really bothers me with the simple-method stuff in OFBiz whenever I >>> use it is the inconsistency between the simple-method, screen actions, >>> form actions, etc, and the inconsistent handling of expressions and such >>> for field, from-field, value, etc attributes. Having everything use the >>> same XSD and having everything actually be a groovy expression (since it >>> is just transformed into a groovy script) made it much easier and less >>> frustrating to use. >> >> I plenty agree with him. Moreover, I think we don't need many syntaxes, as >> long as the one provided supersedes all the others. On a long term, I can >> help to refactor current minilang code (which means also screens and form >> actions of course). >> >> Thanks >> >> Jacques >> >> >> From: "Adrian Crum" <adrian.c...@sandglass-software.com> >>> I think I have come up with a solution to fix the mini-language code: >>> mini-language auto-correction. If enabled, the element models correct >>> common mistakes and save the corrections to the original file. This will >>> still leave some warnings that will need to be fixed manually. >>> >>> -Adrian >>> >>> On 4/3/2012 2:07 PM, Adrian Crum wrote: >>>> I added parsing validation to the <set> element to see how it will work. >>>> The validation can be enabled/disabled through a property setting. >>>> >>>> Just running the load-demo ant task generates hundreds of warnings - most >>>> of them are caused by <set> attributes being used incorrectly. On the >>>> positive side, a lot of nonsensical code is being revealed; on the >>>> negative side, the log is filled with warnings. >>>> >>>> I'm not sure what I will do with this. If I commit the validation code, >>>> then we will have a lot of work to do to clean up the mini-language code. >>>> >>>> -Adrian >>>> >>>> On 3/8/2012 6:55 PM, Adrian Crum wrote: >>>>> Some more food for thought... >>>>> >>>>> Looking through the Java code, I can see that there is no runtime >>>>> validation being performed. Granted, a decent XML editor will warn you >>>>> about required attributes and elements and such, but not everyone uses >>>>> that type of XML editor. Worse yet, there is no way to know you've done >>>>> something wrong - because mini-lang hides the errors in verbose log >>>>> statements. So, I would like to add runtime validation. If the script is >>>>> coded improperly, then it should throw an exception. >>>>> >>>>> Another change I would like to make is to remove default attribute values >>>>> in the schema. From my perspective, defaults should be in the >>>>> mini-language code. The wiki page has demonstrated to me how difficult it >>>>> is to understand what's going on when you have to look through Java code, >>>>> and then also look through the schema to see what values it is supplying. >>>>> Plus, it makes me wonder how mini-language will behave when the server >>>>> doesn't have access to the schema. >>>>> >>>>> Which brings up another point: Once the grammar has been cleaned up, we >>>>> will need a new schema. I think we need to start giving our schemas >>>>> version numbers so that XML editors and runtime XML validation will work >>>>> properly. >>>>> >>>>> -Adrian >>>>> >>>>> >>>>> On 3/8/2012 6:19 PM, Jacopo Cappellato wrote: >>>>>> On Mar 8, 2012, at 7:03 PM, Adrian Crum wrote: >>>>>> >>>>>>>> B) instead of: >>>>>>>> >>>>>>>> <fail-property resource="ErrorMessages" property="FooError" /> >>>>>>>> >>>>>>>> we could have >>>>>>>> >>>>>>>> <fail-property property="ErrorMessages.FooError" /> >>>>>>> Keep in mind that UEL would interpret FooError as an element of a Map >>>>>>> called ErrorMessages. >>>>>>> >>>>>>> What you suggested can be done, but it will require more modifications >>>>>>> to the UEL integration - something I try to avoid because it causes >>>>>>> more problems than it solves. I recommend we keep the resource >>>>>>> attribute. >>>>>> Np then, I was not even sure it was a good idea and if requires >>>>>> customizations to uel then I agree it is not worth the effort. >>>>>> >>>>>> Thank you, >>>>>> >>>>>> Jacopo
