commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rahul Akolkar (JIRA)" <j...@apache.org>
Subject [jira] Resolved: (SCXML-18) Refactoring of Evaluator.execLocation
Date Thu, 10 Aug 2006 21:03:14 GMT
     [ http://issues.apache.org/jira/browse/SCXML-18?page=all ]

Rahul Akolkar resolved SCXML-18.
--------------------------------

    Resolution: Won't Fix

The association to a Node is via the WD itself (it talks about XML data trees, and appending/relocating
subtrees à la DOM operations). I didn't understand all of your suggestions, eg: why the Evaluator
should do assignments when not all ELs support assignments, or the reference to javax.el.
Plus, as you mention, there are backwards compatibility issues and the suggested changes can
only be completed in the next major release. I'm marking as a WON'T FIX. Feel free to propose
a patch so we can constrast the current Evaluator API bits and the ones you are proposing
(and reopen).


> Refactoring of Evaluator.execLocation
> -------------------------------------
>
>                 Key: SCXML-18
>                 URL: http://issues.apache.org/jira/browse/SCXML-18
>             Project: Commons SCXML
>          Issue Type: Wish
>    Affects Versions: 0.5
>            Reporter: Tuomas Kiviaho
>
> There is a special case public method having return value tied to be a Node from DOM
API in the Evaluator api used only by 'assign' location.
> Implementing the execLocation requires use of Node adapters when the expression doesn't
evaluate to Node. Knowledge how the DOM api is used is required to reduce the amount of work
put adapter implementation.
> Suggestions:
> 1. Declare new method to evaluator that handles assigment and deprecate execLocation.
> 2. Implement evaluator expressions that can both resolve or assignment of values.
> 3. Use some language neutral and already existing evaluator api that suits the needs
but doesn't exceed them either to keep things simple when the spec is finalized and backport
the current evaluator framework to it for backwards compatibility. My current suggestion is
javax.el

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message