[
https://issues.apache.org/jira/browse/SCXML-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ate Douma resolved SCXML-59.
----------------------------
Resolution: Won't Fix
This issue is difficult to fix as no longer (or not yet again) does Commons
SCXML 2.0 support or use Rhino as ecmascript datamodel implementation.
So I cannot verify or even look into this anymore from the context as requested.
With SCXML-213 at least, the <assign> handling has been completely
re-implemented, so if this still is an problem for some, please create a new
issue based on the latest codebase.
> <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: 2.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 was sent by Atlassian JIRA
(v6.3.4#6332)
