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
