[
https://issues.apache.org/jira/browse/SCXML-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rahul Akolkar updated SCXML-59:
-------------------------------
Fix Version/s: 1.0
I see, its worth more thought. The interesting bit to getting back to the
Context abstraction is that the "location" could be a part of some context
member, in that it doesn't have to refer to the entire <data> (it could be some
node therein, identified by XPath, and information on the parent <data> is no
longer available).
>From your summary, it isn't clear whether you mean to propose a solution (down
>the road), but proposals / patches are welcome. Marking this to v1.0 since
>some API additions / changes may be necessary.
> <assign location="..." expr="..."> problem for context with different
> internal XML representation
> -------------------------------------------------------------------------------------------------
>
> Key: SCXML-59
> URL: https://issues.apache.org/jira/browse/SCXML-59
> Project: Commons SCXML
> Issue Type: Improvement
> Affects Versions: 0.6
> Reporter: Ingmar Kliche
> Fix For: 1.0
>
>
> We are currently working on a prototype implementation of a ECMAScript
> context and evaluator based on Rhino.
> It appears that Rhino has its internal context and uses an internal XML
> representation different from org.w3c.dom.node. This means we have to convert
> every XML Node/Document when it is stored into the context into Rhino's
> internal XML representation (e.g. when the datamodel is stored into the
> context). This works fine.
> The problem occurs with the current implementation of <assign location="..."
> expr="...">. Assign uses evalLocation() twice to get two org.w3c.dom.node
> objects (one for location and another for expr). Then the implementation of
> Assign iterates through the two node structures and stores the expr node
> under the location node.
> Doing this, Assign manipulates a variable within the context from outside,
> i.e. it manipulates the XML data tree without using a set() at the context.
> To do this it makes use of object references.
> For our context this appears to be a problem. As mentioned earlier we have a
> different internal XML representation (i.e. other Java classes than
> org.w3c.dom). Therefore our evalLocation() returns a org.w3c.dom.node object
> (as required by the context interface) which is a converted copy of the
> internal XML object. Assign therefore works on our copies and as it does not
> store the result explicitly back into the context we loose it.
> I see the current implementation of Assign therefore as a violation of the
> context abstraction (because Assign manipulates data within the context from
> outside) and propose to change it. I propose to think about a solution which
> avoids data convertion (as described above) whereever possible for
> evaluators/contexts which use different internal (XML) data representation.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
