commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ate Douma (JIRA)" <>
Subject [jira] [Commented] (SCXML-213) Fixing the datamodel handling - reimplement xpath processing, the Data() function and the <assign> action
Date Sat, 15 Nov 2014 03:32:34 GMT


Ate Douma commented on SCXML-213:

An important behavioral change to be aware of:
The <send> action without a specified delay used to deliver the event through the *internal*
I/O event queue.
This however was in violation of the specification (unless target="#_internal" is specified,
which wasn't supported yet).

This behavior now has been changed to be in compliance with the specification, so such <send>
actions will now deliver the event through the *external* I/O event queue.
This is important, because the Commons SCXML executor will NOT automatically process external
events itself: you'll have to invoke SCXMLExecutor.triggerEvents() for that manually!

If you used such <send> actions without a specified delay, be aware this WILL cause
a behavioral change in your SCXML execution!!
You either have to now handle such events manually, like described above, OR specify <send
target="#_internal" ...> (which now IS supported) to retain the earlier behavior.

> Fixing the datamodel handling - reimplement xpath processing, the Data() function and
the <assign> action
> ---------------------------------------------------------------------------------------------------------
>                 Key: SCXML-213
>                 URL:
>             Project: Commons SCXML
>          Issue Type: Improvement
>    Affects Versions: 2.0
>            Reporter: Ate Douma
>            Assignee: Ate Douma
>             Fix For: 2.0
> The current datamodel handling, using JAXP based xpath expressions, the custom Data()
function and the implementation of the <assign> action is very limited, incomplete,
and not at all SCXML spec compliant.
> JAXP based xpath expressions require a predefined datatype to be specified for the result,
which is pretty much a blocker, as it cannot be known upfront by the SCXML engine what the
intended datatype should be.
> As as consequence the current XPathEvaluator always converts the result of an normal
(eval) expression to type String.
> And the result of a location expression must be a NodeSet of which only the first Node
element is returned.
> For example an XPath variable cannot be used as assignment location, which this must
be supported by the SCXML specification.  
> The Builtin#data() method (as implementation of the Data() function) always needs an
intermediate single Node result from the #dataNode location method, 
> after which the Node its String content is *tried to* be converted to a Double, or else
a Long, or as fallback the String value itself is returned.
> Returning a Node or even a NodeSet currently is not supported (directly), except by using
the (private) #dataNode method to evaluate the 'expr' parameter for the <assign> element.
> The SCXML spec however requires much more extensive expressions, including using a NodeSet
as value AND as target. 
> The SCXML <assign> element as result currently can only deal with a too limited
set of use-cases, not even close to what is required to be supported by the SCXML spec.
> To fix this properly will require some extensive (breaking) changes...
> First of all, I plan to replace the JAXP xpath expression handling with Commons JXPath.
> After tested and experimented with it for quite some time JXPath turns out to fit very
nicely with the SCXML requirements.
> And the JXPath support for xpath expressions applied to 'plain' Java beans makes it extremely
convenient to support and 'navigate' nested SCXML system variables like the,
> without having to 'convert' this into native DOM structures. The current JAXP based xpath
expressions cannot deal with this at all.
> Commons JXPath also makes it possible to properly implement xpath location expressions,
returning JXPath pointer(s) which can be used to detect AND set left hand expressions,
> including xpath variables (and nested Java bean paths as well). 
> And JXPath also will allow redefining and reimplementing the Data() function for non-xpath
expression languages in a more 'native' and straightforward way, with support for non-flattened/converted
return type data.
> Furthermore JXPath can use and map the SCXML Context variables, and thus also the datamodel
entries directly.
> The Data() function now can be properly implemented requiring *only* an xpath expression
instead of also requiring a data node variable to operate against:
> So, instead of Data(node1, 'expr') we then can use Data('expr') where the node node1
itself is directly accessed within the expression.
> With these changes and enhancements the <assign> action then can be reimplemented
to support all the specification requirements.
> To support location expressions targeting datamodel nodes or xpath variables for non-xpath
based languages will require some extra customizations though to be able to access the 'pointer'
of a location target.
> For this purpose probably we need a separate location expression attribute, e.g. xlocation=""
instead of location="" to hint the SCXML engine the location needs to be evaluated as xpath
expression returning pointers, not data.
> All these changes will be rather invasive and potentially breaking for existing SCXML
documents using the Data() function and <assign> element.
> And likely this will take several steps to implement properly with a potentially unstable
intermediate state of the SCXML engine implementation.   
> I'll create separate sub tasks for these steps: the JAXP replacement with Commons JXPath,
the Data() function and related Builtin class changes, and the changes to the <assign>
> Until all these sub tasks are completed the current SCXML trunk might thus become unstable
and probably should *not* be used/tested for current projects...
> Once everything is working again as intended and this umbrella issue has been resolved,
I'll give a heads-up on the users@ list with comprehensive explanations and instructions how
to 'migrate' to the new implementation.  

This message was sent by Atlassian JIRA

View raw message