Return-Path: 
 <issues-return-44220-apmail-commons-issues-archive=commons.apache.org@commons.apache.org>
X-Original-To: apmail-commons-issues-archive@minotaur.apache.org
Delivered-To: apmail-commons-issues-archive@minotaur.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 877B010A21
	for <apmail-commons-issues-archive@minotaur.apache.org>;
 Sat, 15 Nov 2014 04:35:38 +0000 (UTC)
Received: (qmail 87689 invoked by uid 500); 15 Nov 2014 04:35:34 -0000
Delivered-To: apmail-commons-issues-archive@commons.apache.org
Received: (qmail 87575 invoked by uid 500); 15 Nov 2014 04:35:34 -0000
Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:issues-help@commons.apache.org>
List-Unsubscribe: <mailto:issues-unsubscribe@commons.apache.org>
List-Post: <mailto:issues@commons.apache.org>
List-Id: <issues.commons.apache.org>
Reply-To: issues@commons.apache.org
Delivered-To: mailing list issues@commons.apache.org
Received: (qmail 87496 invoked by uid 99); 15 Nov 2014 04:35:34 -0000
Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 15 Nov 2014 04:35:34 +0000
Date: Sat, 15 Nov 2014 04:35:34 +0000 (UTC)
From: "Ate Douma (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Message-ID: <JIRA.12378949.1190572432000.507157.1416026134369@Atlassian.JIRA>
In-Reply-To: <JIRA.12378949.1190572432000@Atlassian.JIRA>
References: <JIRA.12378949.1190572432000@Atlassian.JIRA>
 <JIRA.12378949.1190572432879@arcas>
Subject: [jira] [Closed] (SCXML-59) <assign location="..." expr="...">
 problem for context with different internal XML representation
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394


     [ https://issues.apache.org/jira/browse/SCXML-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ate Douma closed SCXML-59.
--------------------------

> <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
>
> 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)