Ok, It's clear, the sentence "This is a draft document. It can be
modified at any time by anyone." is disturbing in this case.
Maybe change it by "This is a draft document. Send your comments on dev
mailing" ?
Nicolas
Le 15/03/2012 14:02, Adrian Crum a écrit :
Yes, edit access is restricted to committers.
Comments on the draft should be posted here. I want to make sure the
discussion stays on the mailing list so everyone can participate.
-Adrian
On 3/15/2012 12:42 PM, Nicolas Malin wrote:
Hi Adrian,
I tried to edit the Mini-language+Reference page to adding my comment
on entity-condition, but how to edit it ?
This page is in OFBiz Admin space on confluence and I have not edit
access on this space, maybe you want that only commiter and PMC edit
the draft ?
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/
