Guvnor currently (and always has AFAIK) constructed metadata as "@name(value)" i.e. no quotation marks around the value.<br><br>Is this still valid, or do we need to make a change to support the underlying change?<br>
<br>Thanks,<br><br>Mike<br><br><div class="gmail_quote">On 29 April 2011 23:30, Wolfgang Laun <span dir="ltr"><<a href="mailto:wolfgang.laun@gmail.com">wolfgang.laun@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br><br><div class="gmail_quote"><div class="im">On 29 April 2011 19:18, Edson Tirelli <span dir="ltr"><<a href="mailto:ed.tirelli@gmail.com" target="_blank">ed.tirelli@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div><br></div> Wolfgang, <div><br></div><div> It seems to me that what we need to to improve the solution to address the problems you listed, but we are better now then we were before, as we support everything that was supported in 5.1 + the new use cases.</div>
</blockquote></div><div><br>Correct!<br><br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div><br></div><div> Did I miss something?</div><div><br></div></blockquote><div>Only if you intend to do, in a later release, <a href="http://s.th" target="_blank">s.th</a>. with those expressions, such as evaluate them if they are all literal, or maybe with imported variables, if that can be done at all. If yes, the thing I'd propose is to either announce (clearly!) the future change ("expressions will not remain expressions returned as Strings") OR reduce the accepted expressions to single literals of the basic types, which could be converted to Integer/String/Boolean objects according to their natural syntax.<br>
<br>Perhaps the concatenation of duplicated inner Map values should be removed - I'm afraid I did that, in an effort to avoid silent overwriting, which definitely isn't better; both is bad.<br><font color="#888888"><br>
Wolfgang<br> </font></div><div><div></div><div class="h5">
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div></div><div> Edson<br><br><div class="gmail_quote"><div><div></div><div>2011/4/29 Wolfgang Laun <span dir="ltr"><<a href="mailto:wolfgang.laun@gmail.com" target="_blank">wolfgang.laun@gmail.com</a>></span><br>
</div></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><div></div><div>The current parser handles metadata annotations<br>
<br> '@' <i>Identifier</i> '(' <i>Text</i> ')'<br>
<br>so that the annotations for one entity (e.g., a rule) are available as a Map<String,Object>, where the key is given by the <i>Identifier </i>and the value of the entry is available according to<br>
<br><b>if</b> <i>Text</i> can be <i>completely</i> parsed as <i>Identifier</i> '=' <i>Expression</i> (where <i>Expression</i> is whatever the DRL parser accepts as an expression, i.e., an extended subset of Java expressions)<br>
<b>then</b><br> the value is a Map<String,String><br> <b>else<br> the </b>value is a String, with trimmed leading and trailing white space, but preserving all embedded white space<br><br>Changes compared to 5.1.1:<br>
- no Map was ever returned in 5.1.1,<br> - @m( "foo" ) in 5.1.1. returned "foo", but 5.2.0 returns "\"foo\"".<br> - @m( "foo", "bar" ) in 5.1.1. returned "foo\", \"bar", but 5.2.0 returns "\"foo\", \"bar\""<br>
- comments between "@...(" and ")" are now handled consistently but were not in 5.1.1<br><br>Possibly considered a problem for 5.2.0 or later:<br>- No check is made for duplicate "outer" map keys; entries are overwritten.<br>
- Repeated "inner" map keys produce concatenated entries, e.g. @m( k = 1, k = "a" ) returns "1a" as the value for key "k".<br>- Returning (arbitrary) expressions, unchanged, as String now may cause incompatibilitie with more sophisticated processing (if this ever should be considered).<br>
<font color="#888888">
<br>-W<br><br><br><br><br><br><br><br><br><br>
</font><br></div></div>_______________________________________________<br>
rules-dev mailing list<br>
<a href="mailto:rules-dev@lists.jboss.org" target="_blank">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></blockquote></div><br><br clear="all"><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>
</div>
<br>_______________________________________________<br>
rules-dev mailing list<br>
<a href="mailto:rules-dev@lists.jboss.org" target="_blank">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></blockquote></div></div></div><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>
<br></blockquote></div><br>