Adrian, what is your plan ? you want to use mini-lang for development and compile to java at the same time ?! Issues with recompile can resolved with an ant task that monitors src directory for changes, and trigger a recompile when changes occur. Reloading the compile java can be by external utilities. Honestly, I don't think this is should be done by the framework, as it makes it harder to maintain.
Tools that can reload java classes like jrebel (commercial), hotswap, jreloader ... etc. On Wed, Mar 7, 2012 at 11:22 PM, Adrian Crum <adrian.c...@sandglass-software.com> wrote: > That's one of the advantages to mini-language - you don't need to compile > it. It would be nice to have a tool that converts schemas to Java model > classes however. > > -Adrian > > > On 3/7/2012 11:35 PM, Mansour Al Akeel wrote: >> >> Not sure if this discussion open for users as well. >> >> I don't use mini-lang, and prefer to do things in java. But I am >> wondering why not move all the repetitive code to java (copying >> fields). Those who prefer to use mini-lang can have an XSLT that will >> produce the java code as they want. This way, every contributor can >> customize their XSLT and have their grammar that will produce the java >> code. Maintenance will not be possible with mini-lang, since the code >> generated is committed to SVN is in java. >> >> >> >> >> On Wed, Mar 7, 2012 at 1:18 PM, Adrian Crum >> <adrian.c...@sandglass-software.com> wrote: >>> >>> 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 >>>>>>>>>>>> >
