[
https://jira.jboss.org/jira/browse/JBRULES-1675?page=com.atlassian.jira.p...
]
Mark Proctor commented on JBRULES-1675:
---------------------------------------
I'd rather see this done through something like SXC, which provides efficient XPath
evaluation:
http://sxc.codehaus.org/XPath
What I don't like about SXC is it forces you to use it's evaluators, instead of
returning the value(s) for Drools to evaluate.
Mark
Xpath Default Constraint Evaluations
------------------------------------
Key: JBRULES-1675
URL:
https://jira.jboss.org/jira/browse/JBRULES-1675
Project: Drools
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: drools-compiler, drools-compiler (expert), drools-eclipse,
drools-verifier
Reporter: Paul Ryan
Assignee: Mark Proctor
A default set of constraint matchers for xpath based on loaded w3c DOMs would be very
helpful. For our project we have alot of facts that are just an xml file (this seems to be
the way the industry in general is going) that is calculated and being able to load that
in to working memory and have constraint based node evaluations would be a very nice and
attractive feature. I would suggest as a start a basic content equals (on elements it
would match against text content and on attributes it would match against the node value)
as well as a basic check for exists based on given xpath.
Potential syntax:
Fact( xml.xpath("/document//fragment[@id='myid']")) // Checks if the
xpath exists in the property xml
or
Fact( xml.xpath("/document//fragment[@id='myid']") ==
"myvalue") // Checks if the text content of the fragment with the given id is
"myvalue"
or
Fact( xml.xpath("/document//fragment[@id='myid']/@attr1") ==
"myattr") // Checks if the node value of the attribute attr1 in the given
fragment is "myattr"
with the property xml having been defined in the fact.
I would suggest implementing this using the latest DOM stuff that has been recently
released with xerces 2.9 and up as it has a very fast and efficient xpath evaluator. If
you would like I think I can draw up some examples, however I don't think I know
enough about drools core code to write this feature myself yet, maybe with some help.
Also this constraint module may need a new interface for configuring the size limit (or
other constraint) around when to load the xml into working memory. Maybe a annotation
based solution in the fact is a good idea (e.g. put an annotation @LoadDOM on xml property
in the fact for properties that should be loaded into DOM), or the other option is that
the designer has to set the property up as an org.w3c.dom.Document for it to be consider
pre-loadable.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira