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.l...@gmail.com> wrote:
>
>
> On 29 April 2011 19:18, Edson Tirelli <ed.tire...@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.l...@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@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@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
