On 3 January 2011 16:18, Edson Tirelli <span dir="ltr"><<a href="mailto:ed.tirelli@gmail.com">ed.tirelli@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi Wolfgang,<br>
<br>
It looks very good. My only concern is how it affects the eclipse<br>
plugin, specially the line breaks. I am guessing we will have to<br>
change it to support that?<br>
<br></blockquote><div>Good catch. I would not expect the Eclipse editor to keep the line breaks, but it seems<br>that it fails to continue reading entries after the first split entry. :-{<br>Can this be fixed without busting a vein? Given that "Language Expression" and "Rule<br>
Language Mapping" could both be multiline, the widget structure in the DSL Editor<br>would need some rework. But it sure would benefit, too.<br><br>(I can't imagine how anybody could edit a complex DSL with this editor. Even minor<br>
changes in the DSL require you to reorder the entries, and I don't see how you can<br>do this in the Eclipse editor. And there's no "find", no "find/replace", etc... This<br>editor just isn't going to clinch it.)<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Also, does any of these changes break backward compatibility?<br></blockquote><div><br>None I'm aware of. <br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
In case it doesn't, my vote is to apply all the changes listed.<br></blockquote><div><br>OK, which means I'll go ahead and fix the Expert doc.<br>-W</div><div><br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Edson<br>
<br>
<br>
2011/1/3 Wolfgang Laun <<a href="mailto:wolfgang.laun@gmail.com">wolfgang.laun@gmail.com</a>>:<br>
<div><div></div><div class="h5">> Probably sent not at the best of times, this didn't get a peep from anyone.<br>
> Please do comment, for the reasons stated below.<br>
> -W<br>
><br>
> On 24 December 2010 11:23, Wolfgang Laun <<a href="mailto:wolfgang.laun@gmail.com">wolfgang.laun@gmail.com</a>> wrote:<br>
>><br>
>> This is a summary of the currently implemented new features for the DSL<br>
>> expansion. I'll have to add tests and documentation, but before doing so,<br>
>> I'd like to learn whether there are any objections (resulting in the<br>
>> removal) or suggestions for improvement. Myself, I'm not sure about one or<br>
>> two items which I've marked with "(?)". Also, there's a couple of items<br>
>> which might gain from easy-to-implement additions, see "Votes, please". An<br>
>> example showing most of the new options is given below.<br>
>><br>
>> The right hand side of entry definitions can be empty. (Useful for<br>
>> deleting "filler" phrases.)<br>
>> Long entry lines can be split without the need of escaping EOL:<br>
>><br>
>> Any line beginning with # or // starts a DSL comment and is not passed to<br>
>> the DSL parser.<br>
>> Any line beginning with '[' starts a new entry.<br>
>> All other lines are appended to the preceding line, with a space replacing<br>
>> EOL.<br>
>> Empty lines are inserted to maintain original line numbers, and line and<br>
>> column numbers in error messages from the parser are recalculated to reflect<br>
>> the user view of the DSL text.<br>
>><br>
>> The special comment introduction "#/" is used to mark a line containing<br>
>> debug options. Currently recognized keywords are:<br>
>><br>
>> result - dumps the resulting DRL<br>
>> steps - shows all expansion operations in conditions and consequences<br>
>> keyword, when, then - display the corresponding entry definitions<br>
>> usage - shows how often an entry was actually used in an expansion<br>
>><br>
>> Variable substitution uses the definition of that variable seen last in<br>
>> the current when or then part expansion. not just from the current line.<br>
>> (But this probably should keep variables from the when part for the<br>
>> following then part. Votes, please.)<br>
>> The value used in a variable substitution can be modified on the fly by<br>
>> adding one of the modifiers after and '!' in the variable reference.<br>
>> Currently recognized modifiers are:<br>
>><br>
>> uc, lc - convert all letters to upper case or lower case, respectively<br>
>> ucfirst - convert the first letter to upper case, and all other letters to<br>
>> lower case<br>
>> num - extract all digits and a '-' preceding the first digit and insert<br>
>> the numeric value; a '.' or ',' two digits from the right is retained as a<br>
>> decimal point, which is useful for monetary quantitites. (?)<br>
>><br>
>> Another modification of the value used for substituting the reference is<br>
>> by providing a "multiple choice" after an '!', consisting of strings<br>
>> separated alternatively by '?' and '/': If the string extracted from the<br>
>> DSLR line matches the string before a '?', the string following it is used<br>
>> for substitution; otherwise test the next choice. (?)<br>
>> A DSL value starting with a hyphen ('-') can also be used in a consequence<br>
>> to add another setter expression into a preceding "modify(x){}". (Should<br>
>> probably be extended to be able to handle the insertion of another parameter<br>
>> to any preceding method call and, as a special, but useful, case the<br>
>> concatenation to a preceding x.println() or x.print() call. Votes, please.)<br>
>><br>
>> DSL:<br>
>> [when][][Tt]here is an?=<br>
>> [when][]{entity} called {x}=<br>
>> ${entity!lc}: {entity!ucfirst}( $name:<br>
>> name=="{x!M?Mark/E?Edson/G?Geoffrey/unknown}")<br>
>> [when][]and no other with the same {attr}=not {entity!ucfirst}( {attr} ==<br>
>> ${attr} )<br>
>> [then][]change person=modify($person)\{\}<br>
>> [then][]- set {attr} to {value} = set{attr!ucfirst}( {value!num} )<br>
>><br>
>> DSLR:<br>
>> rule "Rule 1"<br>
>> when<br>
>> There is a PERSON called M<br>
>> and no other with the same name<br>
>> then<br>
>> change person<br>
>> - set salary to US$9,999.99<br>
>> - set rank to "colonel"<br>
>> end<br>
>><br>
>> DRL:<br>
>> 8 rule "Rule 1"<br>
>> 9 when<br>
>> 10 $person: Person( $name: name=="Mark")<br>
>> 11 not Person( name == $name )<br>
>> 12 then<br>
>> 13 modify($person){ setSalary( 9999.99 ), setRank( "colonel" ) }<br>
>> 14 end<br>
>><br>
>> Cheers<br>
>> Wolfgang<br>
>><br>
>><br>
><br>
><br>
</div></div>> _______________________________________________<br>
> rules-dev mailing list<br>
> <a href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/rules-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-dev</a><br>
><br>
><br>
<br>
<br>
<br>
--<br>
Edson Tirelli<br>
JBoss Drools Core Development<br>
JBoss by Red Hat @ <a href="http://www.jboss.com" target="_blank">www.jboss.com</a><br>
<br>
_______________________________________________<br>
rules-dev mailing list<br>
<a href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/rules-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-dev</a><br>
</blockquote></div><br>