[
https://issues.apache.org/jira/browse/SCXML-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15084105#comment-15084105
]
Woonsan Ko commented on SCXML-242:
----------------------------------
I got one more suggestion (or wish):
- If ContentParser#parseResource(final String resourceURL) could handle
classpath resource URLs as well, then it would be more useful in practice, IMHO.
- Then data source can be specified with a resource path in the classpath.
For example,
{code:title=Before}
public Object parseResource(final String resourceURL) throws IOException {
InputStream in = null;
try {
in = new URL(resourceURL).openStream();
String content = IOUtils.toString(in, "UTF-8");
return parseContent(content);
}
finally {
IOUtils.closeQuietly(in);
}
}
{code}
{code:title=After}
public Object parseResource(final String resource) throws IOException {
InputStream in = null;
try {
final URI resourceURI = URI.create(resource);
URL resourceURL = null;
if (resourceURI.isAbsolute()) {
resourceURL = resourceURI.toURL();
} else {
resourceURL =
Thread.currentThread().getContextClassLoader().getResource(resource);
}
in = resourceURL.openStream();
String content = IOUtils.toString(in, "UTF-8");
return parseContent(content);
}
finally {
IOUtils.closeQuietly(in);
}
}
{code}
> Provide JSON based datamodel as replacement for XML/XPath
> ---------------------------------------------------------
>
> Key: SCXML-242
> URL: https://issues.apache.org/jira/browse/SCXML-242
> Project: Commons SCXML
> Issue Type: New Feature
> Reporter: Ate Douma
> Assignee: Ate Douma
> Fix For: 2.0
>
>
> The XML/XPath datamodel, with 'convenient' support through Data() and
> Location() operations for usage within the Jexl, Javascript and Groovy SCXML
> languages has been the root and cause of many invasive and complicating
> problems in the implementation of Commons SCXML (2.0).
> The [SCXML 1.0 specification|http://www.w3.org/TR/2015/REC-scxml-20150901/]
> has dropped the xpath datamodel from the specification because of
> similar/same complications and (also thereof) lack of 'reference'
> implementations.
> Further maintaining and trying to 'improve' on the XML/XPath datamodel
> support in Commons SCXML therefore will be stopped and removed from the
> implementation all together.
> Instead and as replacement new JSON datamodel support will be added, which
> also aligns with the (optional) Ecmascript datamodel as described in the
> SCXML specification.
> The JSON based datamodel will be parsed (in Java) into a 'raw' object model,
> consisting of plain Maps (JSON Object) and Lists (JSON Array), and thus
> trivially to be used from the Commons SCXML supported languages (Jexl, Groovy
> and Javascript).
> As this new JSON datamodel will replace all XML/XPath usages, part of this
> new feature implementation will be updating and replacing all the
> example/unit-test usages in the codebase, and thereby also removing all
> usages of the custom Data() and Location() functions.
> Once these changes are in place, the Data() and Location() custom functions
> will then be removed as well.
> Finally, the XPath language itself then can be removed, including all the
> supporting logic scattered throughout the engine implementation itself, but
> this will be done as a separate issue afterwards.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
