commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rahul Akolkar (JIRA)" <j...@apache.org>
Subject [jira] Updated: (SCXML-59) <assign location="..." expr="..."> problem for context with different internal XML representation
Date Tue, 25 Sep 2007 20:17:50 GMT

     [ 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.


Mime
View raw message