[
https://issues.apache.org/jira/browse/SCXML-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14213299#comment-14213299
]
Ate Douma commented on SCXML-213:
---------------------------------
This turned out to be quite a challenging task, causing rippeling change
effects through much more of the code base as I already expected.
Reimplementing the xpath handling also had major impact on actions like the
<send> and <invoke>, and all the Evaluator implementations had to be updated as
well.
And many/most of the test-cases, and in particular the SCXML test documents
needed to be updated as well.
The Data() function, which used to take two parameters: the data id and an
xpath expression to be applied to id, now has been changed to need only the
xpath expression itself.
The original Data() function also was used for (XML) data location expressions
(using a ugly internal two step processing), which no longer was feasible to
support all the <assign> requirements, I've introduced a second 'builtin' xpath
function: Location(expression). Similar to the original Data() function, but to
be (only) used for location expressions.
The way the <send> and <invoke> actions use and produce payload data, and the
way this in addition has to be transformed for event payload data also required
extensive changes to these actions. As a bonus, AFAIK I now could fully
implemented all <send> features, including child <content> handling.
But as a side-effect, the EventDispatcher interface and default implementation
had to be largely rewritten as well.
The original SimpleDispatcher (which was kind of used by default) actually was
far to simple (really not doing anything), and the SimpleScheduler (dispatcher)
implementation was very limited still.
I've decided to 'collapse' these two implementations onto the SimpleDispatcher
(dropping the SimpleScheduler) and applied the improvements only there.
So now there is only a single default EventDispatcher implementation, the
SimpleDispatcher.
Last but not least, I've also updated the <invoke> implementation as well as
the execution thereof: moving most of the logic from the SCXMLSemanticsImpl to
the Invoke class itself (now extending Action).
The current Invoke implementation isn't finished yet (although already much
further spec compliant than before), but I'm reserving that for a separate
issue.
All in all, there are so many interdependent changes that committing these in
logical incremental steps really isn't possible without the build to be
completely broken.
So there will be one large commit for all the above changes and fixes.
But I've a few more extra and 'standalone' features ready for which I'll create
separate issues and commit separately as well.
> Fixing the datamodel handling - reimplement xpath processing, the Data()
> function and the <assign> action
> ---------------------------------------------------------------------------------------------------------
>
> Key: SCXML-213
> URL: https://issues.apache.org/jira/browse/SCXML-213
> 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 _event.data,
> 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> action.
> 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
(v6.3.4#6332)
