Something like that (FTL-based converter) would be useful for a tool to
batch convert mini-language to Groovy. From my perspective, such a tool
would need to be in place before we can seriously consider changing over
to Groovy. Interest in mini-language may be diminishing, but there is
still a mountain of code written in it. Converting all of it by hand
would be nearly impossible.
-Adrian
On 3/15/2012 6:02 AM, Jacopo Cappellato wrote:
Very interesting, thank you David.
By the way, and slightly off topic, in the future of OFBiz I am having an hard
time to find the real need for these Minilang/xml-actions: in my opinion Groovy
supported by a simple DSL (or call it how you want) would cover all the needs
(in screens, events, services etc...) with the same consistent language.
Jacopo
On Mar 15, 2012, at 6:42 AM, David E Jones wrote:
If you translate the entire simple-method into a groovy script (perhaps
using an FTL file) and then compile/cache/run that groovy script you can
avoid these overhead problems... and also trim the size of the code to
execute simple-methods by a LOT (ie all those Java objects per
simple-method operation would go away).
As an example the template in Moqui that does just this is available here:
https://github.com/jonesde/moqui/blob/master/framework/template/XmlActions.groovy.ftl
One nice thing about this is that everything is groovy by default so you
can inline it anywhere.
For debugging whenever there is an error just log the generated groovy
script (with lines numbers) along with the error message so you can
easily see where the problem happened and why.
-David
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.
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.
-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
