Discussion: Mini-language Overhaul

[Adrian Crum-3]

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

[Erwan de FERRIERES]

Le 03/04/2012 15:07, Adrian Crum a écrit :

> 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
>

Maybe you could attach your work to a Jira issue or create a branch ?


--
Erwan de FERRIERES
www.nereide.biz

[Adrian Crum-3]

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

[Jacques Le Roux]

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" <[hidden email]>

>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

[Adrian Crum-3]

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" <[hidden email]>
>> 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

[Jacopo Cappellato-4]

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" <[hidden email]>
>>> 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

[Jacques Le Roux]

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" <[hidden email]>

>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" <[hidden email]>
>>>> 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
>
>

[Adrian Crum-3]

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" <[hidden email]>
>> 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" <[hidden email]>
>>>>> 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
>>
>>

[Jacopo Cappellato-4]

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" <[hidden email]>
>>> 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" <[hidden email]>
>>>>>> 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
>>>
>>>

[Jacques Le Roux]

Thanks Adrian,

This all makes sense indeed

Jacques

From: "Jacopo Cappellato" <[hidden email]>

>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" <[hidden email]>
>>>> 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" <[hidden email]>
>>>>>>> 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
>>>>
>>>>
>
>