Some of the tests in the SCXML test suite test to ensure that assigning to a data model value location is illegal if there did not pre-exist a <data> element declaring the location. For example, test 286. Is this a limitation of the ECMAScript data model only?
I don't see anywhere in the specs that this is explicitly mentioned. In particular, Section 5.4 on <assign> says only:
"Assignment to a data model is done by using a location expression to denote the part of the data model where the insertion is to be made. If the location expression does not denote a valid location in the data model […] the SCXML Processor must place the error 'error.execution' in the internal event queue.”
I cannot find any other definition of what constitutes a "valid location". I assume that it is up to the data model to determine that. For my Lua-based data model, any possible value of the location attribute is a "valid location". I auto-vivify data model locations upon first value creation, be it via either <data> or <assign>.
Is there a strong reason to require data model locations to be declared with <data> before later <assign>?
Le 16 apr 2014 à 00:54, Gavin Kistner <[hidden email]> a écrit :
Obviously this feature wasn't intended for dynamic languages like ECMAScript and Lua. An <assign> with no expr would serve well enough in our case.
So far, yes. Although the spec isn't quite so strict. The location must exist, but it doesn't have to be declared with a <data> element. It can be created within a <script>, for example.
Note that <data> can only declare global locations (more on that later).
C.2.7 defines the case where <assign> must raise an error. It isn't very explicit, but it should do so when the assignment is not possible (I wish it said "only if"). When the assignment is possible, the interpreter "must" perform it regardless of declarations. The consequence is that an assignemnt that works in ECMAScript must also work in the ECMAScript datamodel, unless it is to a read-only location, in which case <assign> raises an error.
I think what you mean is that any string is a valid property name, which is also true for ECMAScript. But the value of the "location" attribute should be evaluated as an expression, not a name like the unfortunate "id" attribute of <data> elements.
Take this raw attribute value for example: "someObj.p"
If you write <data id="someObj.p"/> it will create a global property named "someObj.p".
If you want to assign to that property with <assign>, you will have to index the global object (in ECMAScript):
<assign location="this['someObj.p']" …/>
Because if you just write this:
<assign location="someObj.p" …/>
you're assigning to the "p" property of someObj.
In reply to this post by Gavin Kistner-4
You are correct that the definition of "valid location" depends on the data model. All the spec is trying to do is to define what the interpreter should do if someone assigns to a location that the underlying data model won't allow/cannot access.
The prose in test286 is wrong. <a class="moz-txt-link-freetext" href="conf:invalidLocation=">conf:invalidLocation="" should be converted into whatever counts as an invalid location in your data model.
On 4/15/2014 6:54 PM, Gavin Kistner wrote:
|Free forum by Nabble||Edit this page|