[rules-dev] @metadata: status; compatibility issues

[Michael Anstis]

Guvnor currently (and always has AFAIK) constructed metadata as
"@name(value)" i.e. no quotation marks around the value.

Is this still valid, or do we need to make a change to support the
underlying change?

Thanks,

Mike

On 29 April 2011 23:30, Wolfgang Laun <wolfgang.laun at gmail.com> wrote:

>
>
> On 29 April 2011 19:18, Edson Tirelli <ed.tirelli at gmail.com> wrote:
>
>>
>>    Wolfgang,
>>
>>    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.
>>
>
> Correct!
>
>
>
>>
>>    Did I miss something?
>>
>> Only if you intend to do, in a later release, s.th. 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.
>
> 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.
>
> Wolfgang
>
>
>>    Edson
>>
>> 2011/4/29 Wolfgang Laun <wolfgang.laun at gmail.com>
>>
>>> The current parser handles metadata annotations
>>>
>>>   '@' *Identifier* '(' *Text* ')'
>>>
>>> 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 *Identifier *and the
>>> value of the entry is available according to
>>>
>>> *if*  *Text* can be *completely* parsed as   *Identifier* '=' *
>>> Expression* (where  *Expression*  is whatever the DRL parser accepts as
>>> an expression, i.e., an extended subset of Java expressions)
>>>    *then*
>>>       the value is a Map<String,String>
>>>    *else
>>>      the *value is a String, with trimmed leading and trailing white
>>> space, but preserving all embedded white space
>>>
>>> Changes compared to 5.1.1:
>>>    - no Map was ever returned in 5.1.1,
>>>    - @m( "foo" ) in 5.1.1. returned "foo", but 5.2.0 returns "\"foo\"".
>>>    - @m( "foo", "bar" ) in 5.1.1. returned "foo\", \"bar", but 5.2.0
>>> returns "\"foo\", \"bar\""
>>>    - comments between "@...(" and ")" are now handled consistently but
>>> were not in 5.1.1
>>>
>>> Possibly considered a problem for 5.2.0 or later:
>>> - No check is made for duplicate "outer" map keys; entries are
>>> overwritten.
>>> - Repeated "inner" map keys produce concatenated entries, e.g. @m( k = 1,
>>> k = "a" ) returns "1a" as the value for key "k".
>>> - Returning (arbitrary) expressions, unchanged, as String now may cause
>>> incompatibilitie with more sophisticated processing (if this ever should be
>>> considered).
>>>
>>> -W
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> rules-dev mailing list
>>> rules-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>>
>>>
>>
>>
>> --
>>   Edson Tirelli
>>   JBoss Drools Core Development
>>   JBoss by Red Hat @ www.jboss.com
>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20110504/d98d1f01/attachment.html