I agree that the overhaul will help to improve existing code (and fix bugs) and also facilitate the migration to Groovy.
Jacopo On Apr 5, 2012, at 12:27 PM, Adrian Crum wrote: > I don't think we will be able to eliminate mini-language entirely. As David > has mentioned, and I agree - it is very convenient to add a few lines of XML > to a screen widget (or service definition in his example). > > The purpose of the overhaul is to fix the numerous issues in mini-language > that have been there for years. I believe those issues are partially > responsible for the waning interest in mini-language. My hope is that the > overhaul will inspire a renewed interest in the language. If that doesn't > happen, then at least we will have a decent reference and implementation that > can be spun off to a separate project. > > If a migration from mini-language to groovy were to take place, then I would > recommend creating a utility to perform the conversion. As I have mentioned > previously, there is a mountain of mini-language code in OFBiz, and > converting it all manually will be impossible. A conversion utility will > depend upon reliable mini-language source code (the XML files, not the Java > source). My initial tests with mini-language <set> element validation have > shown that there are a lot of errors and nonsensical code in the existing > mini-language XML code base. A conversion utility will have a hard time > making sense of it. Therefore, from my perspective, regardless of whether > mini-language stays or goes, some work will need to be done to clean up the > existing mini-language XML code base. > > -Adrian > > On 4/5/2012 10:54 AM, Jacques Le Roux wrote: >> From a pragmatic point of view I'd not be against. The less syntaxes the >> better, and I know a lot of users are not using minilang >> for this reason. But it seems Adrian has already begin to work on the >> Mini-language Overhaul... >> >> Adrian should we not concentrate our efforts on reducing syntaxes in OFBiz? >> On the other hand I know replacing all minilang code in OFBiz would be a >> long and "risky" task... >> >> Jacques >> >> From: "Jacopo Cappellato" <[email protected]> >>> 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" <[email protected]> >>>>>> 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 >>> >>>
