Anyone got a definitive guide as to how Mendix XPath differs from official Xml Xslt XPath?

1
There is a little naughtiness going on. Mendix is calling their query path XPath. As far as I can see this is not official XPath as one would use it in an XSLT (Extensible Stylesheet Language Transformations) file, that is to say how one would navigate and query an Xml DOM (Document Object Model) node tree. Here is official specification http://www.w3.org/TR/2001/WD-DOM-Level-3-XPath-20010830/DOM3-XPath.html Putting that to one side has anyone who comes from an Xml background been through the learning curve for Mendix Xpath and has a cheat sheet of the differences/similarities?
asked
2 answers
3

I have a background in XML/XSLT, these are the things that came to mind:

  1. Comparing nodes doesn't require the complete path. When I started working with Mendix, this really confused me. Example - comparing node Z to node A:

'real' XPath: X/Y/Z = A

Mendix XPath: X/X_Y/Y/_Z = A

  1. No usage of these XPath selectors:
    • self (In case of self reference X/X_X, use X/X_X[reversed()])
    • text-node (Just use the variable that stores the text like $Entity/TextString)
    • axes (ancestor/descendant/sibling) selectors (No tree data structure, so not really needed)
    • distinct
    • pipe (|)
    • some mathematical functions (mod)
    • wildcards as a type of node (*)
    • first() and last() (use Mendix XPath subclauses and subretrieves to get around this)
    • @-selector for attributes (not needed as Mendix provides means to do this itself)
    • string operators like normalize-space (again, Mendix provides non-XPath means for this).
    • string-length() is available in Mendix as the function length().

So don't try anything like

//BBB[ position() = floor(last() div 2 + 0.5) or position() = ceiling(last() div 2 + 0.5) ]

For basic retrieve functionality, Mendix XPath fulfills the basic needs. A nice addition to original XPath are system variables and tokens, like [$SomethingWithDate/Date = [%BeginOfCurrentDay%]] though. :)

answered
1

Have you reviewed the Mendix reference guide for XPath?

I think the main differentiating factor between the full XPath specification and what you end up writing in Mendix is here in that article:

In the Modeler you do not write complete queries but only the constraints. The entity is implicitly determined by the context. So, instead of //Sales.Customer[Name='Jansen'] you only write [Name='Jansen']

There are some other differences in terms of which date constants are available to you, and also the fact that you can use variables in microflows to complete your XPath constraints.

All in all, if you're coming from a background where you've used XML XPath, you will probably pick up the Mendix style of writing XPath constraints rather quickly.

answered