This is a good list. Thanks Jacopo!
There are some issues with your suggestions - comments inline...
-Adrian
On 3/8/2012 3:18 PM, Jacopo Cappellato wrote:
A) I would like to see removed all the attributes "map-name" and just leave the
"field" attribute; for example:
<clear-field field="foo" map-name="parameters"/>
can be:
<clear-field field="parameters.foo"/>
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.
C) instead of:
<request-to-field>
<session-to-field>
we could have:
<set field="foo" from="parameters.request.inputFoo"/>
<set field="foo" from="parameters.session.inputFoo"/>
That can be done, but with a slight difference:
<set field="foo" from="request.parameters.inputFoo"/>
<set field="foo" from="session.parameters.inputFoo"/>
D) similarly deprecate (replaced by "set"):
<field-to-env>
<field-to-field>
<field-to-list>
<field-to-request>
<field-to-session>
<property-to-field>
<now-timestamp-to-env>
We can eliminate <now-timestamp-to-env> if we just put a nowTimestamp
field in the method context - like we do now with screen widgets.
<now-date-to-env>
<map-to-map>
<list-to-list>
<string-to-field>
<string-to-list>
<to-string>
<webapp-property-to-field>
<set-current-user-login>
I agree all of those can be deprecated.
I don't have more time today but there may be others :-)
Jacopo
On Mar 8, 2012, at 3:16 PM, Nicolas Malin wrote:
Ok thanks adrian
Nicolas
Le 08/03/2012 14:46, [email protected] a écrit :
Voting on each item will not work because there are too many. We can discuss
things here and when there seems to be general agreement, I will ask for a vote
on the entire grammar. When that vote passes, I will include the proposals in
the grammar (move them out of the blue boxes and into the normal text), and
change the status from draft to final.
-Adrian
Quoting Nicolas Malin<[email protected]>:
Thanks adrian for this works,
I will add my propositions.
After all proposition will include on wiki, how to you proceed to approve each
? A vote on mailing list for each ?
Nicolas
Le 07/03/2012 19:18, Adrian Crum a écrit :
I created a Wiki page to help get things started:
https://cwiki.apache.org/confluence/display/OFBADMIN/Mini-language+Reference I
put just enough information in it to work on the layout. I will continue
working on it when I have time. Everyone with write access is welcome to work
on it also. The information is based on the mini-language Java code - which is
the ultimate authority. The schemas are inaccurate - they should be used only
for looking up schema-supplied default values.
The goal is to document the current mini-language grammar, and add proposed
changes. If a proposal is approved, then it can get a green check mark. If a
proposal is vetoed, then it can get a red X. When everyone agrees on the
grammar, the document will be updated, and it will move out of the draft stage.
Then the job will be to work on the Java and XML code to make it match the
grammar.
I put a couple of proposals in the page to help get things started.
Let me know what you think.
-Adrian
On 3/6/2012 9:42 AM, Adrian Crum wrote:
<set field="field4" from="parameters.inputField1 + 10"/> <!-- use Minilang
built-in and efficient support: not currently supported but maybe something to consider in the future -->
The from attribute contains a UEL expression, so it is currently supported.
-Adrian
On 3/6/2012 9:33 AM, Jacopo Cappellato wrote:
On Mar 6, 2012, at 10:03 AM, Adrian Crum wrote:
Replacing FSE with Groovy is a bad idea. Adam and I optimized FSE so that it is
very lightweight and fast. I also optimized the UEL integration so there is
very little overhead in the evaluation process. Switching everything to Groovy
will slow things down and increase memory usage. Also keep in mind that Groovy
creates a class for every script, so we will run out of permgen space again.
Ok, makes perfect sense, thank you.
I think a wiser strategy would be to make mini-lang as feature complete as
possible, and include a from-script attribute for any feature gaps. In other
words, use from-script as a last resort - because it is costly.
+1: by the way we could still use the "from" attribute for both:
<set field="field4" from="parameters.inputField1"/> <!-- use Minilang built-in
and efficient support -->
<set field="field4" from="parameters.inputField1 + 10"/> <!-- use Minilang
built-in and efficient support: not currently supported but maybe something to consider in the future -->
<set field="field4" from="groovy: parameters.inputField1 + 10"/> <!-- use Groovy
(inefficient) -->
Jacopo
-Adrian
On 3/6/2012 8:53 AM, Jacopo Cappellato wrote:
On Mar 6, 2012, at 9:32 AM, Adrian Crum wrote:
I don't understand what you mean by supporting a limited number of types.
Currently, mini-lang supports any type - thanks to the conversion framework.
The conversion framework is fine; I was thinking that we could implicitly (by
default) treat in Minilang all the numbers as BigDecimals, all the strings as
GStrings/Expandable Strings; where special conversions are required than the
type can be specified.
I like the idea of changing the from-field attribute to from. I would like to
see a from-script attribute added:
<set field="field4" from-script="groovy: parameters.inputField1 + 10"/><!-- Use
Groovy -->
and why not:
<set field="field4" from="parameters.inputField1"/><!-- Use Groovy internally:
refactor OFBiz custom code to delegate on Groovy the evaluation of simple assignments; this could potentially
replace FlexibleStringExpander related code -->
<set field="field4" from="groovy: parameters.inputField1 + 10"/><!-- Use Groovy explicitly to evaluate
the expression (use the same "from" attribute instead of a separate "from-script")-->
<set field="field4" from="parameters.inputField1 + 10"/><!-- Use Groovy (by
default, configurable) to evaluate the expression-->
<set field="field4" from="beanshell: parameters.inputField1 + 10"/><!-- Use
Beanshell to evaluate the expression-->
?
Then we can remove script support from expressions, which will eliminate ugly
hacks like:
<set field="field4" value="${groovy: parameters.inputField1 + 10}"/>
+1
Jacopo
-Adrian
On 3/6/2012 7:31 AM, Jacopo Cappellato wrote:
I am a big fan of Minilang too.
The "evolution" strategy that I would like to see implemented for Minilang is
actually the same one I would liketo see applied to OFBiz framework in general: review
the current usage of the tool, fix existing usage for consistency (upgrade old code to
use newer mechanisms offered by the tool), get rid of unused or old mechanisms in the
attempt to slim down the size of the framework code, unify/simplify mechanisms based on
lesson learned; all of this could be useful even to prepare the future migration to a
different tool (e.g. Groovy).
I know that it is very vague and doesn't add much to this thread but I like the
approach suggested by Adrian.
In my opinion, a good way to define a new version of the "set" operation could be that of
analyzing how we are currently using the operation in OFBiz: as a starting point we could start by
searching all occurrences of "<set " string in OFBiz, then review them and see different
patterns; discuss and define the few ones that we like more, convert all code to use them
consistently, then (or in the same phase) define the new element to better implement the patterns that
we like.
And now I am switching to the "brainstorming" mode :-)
Kind regards,
Jacopo
========================
<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...)
* 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
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
--
Nicolas MALIN
Consultant
Tél : 06.17.66.40.06
Site projet : http://www.neogia.org/
-------
Société LibrenBerry
Tél : 02.48.02.56.12
Site : http://www.librenberry.net/
--
Nicolas MALIN
Consultant
Tél : 06.17.66.40.06
Site projet : http://www.neogia.org/
-------
Société LibrenBerry
Tél : 02.48.02.56.12
Site : http://www.librenberry.net/
