Re: [SCXML] Question regarding the meaning and purpose of type 'location expression in namelist and param location attributes

On 29-10-14 10:15, David Junger wrote:
> Le 29 okt 2014 à 01:32, Ate Douma <ate@douma.nu> a écrit :
>>
>> I'm curious: does anyone actually have a working SCXML implementation where
>> using an ECMA "foo.bar" namelist (or even better: the XPath "foo/bar"
>> namelist) works for passing the attribute to the invoked session?
>
> Thing is, it'd be ambiguous in ECMAScript, as we can have
> datamodel["foo.bar"] which would be different from datamodel.foo.bar. In a
> namelist, JSSC simply splits around whitespace, and uses the resulting
> strings as "names", and evals them to get the value, so they can be any
> expression at all (as long as they don't contain whitespace).
>
> Interpreting "foo.bar" as a qualified name would be feasible, but many other
> things are valid left-hand-side expressions in ECMAScript and there's no way
> I'm going to write a parser for "foo(bar){…}.baz[7*i+2]". Not to mention that
> context (scope chain and "this") would not be passed along with the
> expression, so while "this.bar" is a good-looking name, it may behave in a
> strange way.
>
> Anyway, while JSSC will set the "foo.bar" property of an invoked session from
> the namelist, it is not a particularly intuitive behavior and I wouldn't mind
> if nobody ever thought that it was a good idea to try it.
>
Right :)

So indeed this is 'usable', even when targeting SCXML sessions, but as you 
indicate 'barely so', and might just as well break easily depending on how the 
location expression is coded as on which expression language used (which I don't 
even know for the target SCXML session).

Like I already replied to Jim, I'm inclined to not even bother supporting this 
with Apache Commons SCXML.

I probably will only support 'raw' data IDs in a namelist, while location 
expressions still can be used through a properly named <param> element.

Thanks,

Ate


> David
>

Received on Friday, 31 October 2014 01:51:20 UTC