The MForm XPath abbreviated syntax uses the location path construct. A location path may consist of one or more location steps.

The navigation starts from one MForm control (usually a root, but can be started from any MForm control), this control is queried with the first location step from the location path resulting in an enumeration of MForm controls. All of the MForm controls in this enumeration are then queried with the next location step and so on until the last location step, which returns the output result of the whole location path.

Example 2

Assume that we start the navigation from an MForm control that has a child MForm control called "Parent". This control has a child MForm control called "ItsChild", and subsequently this control has a child MForm control called "TheGrandChild".

The path that directs to the last control would look like this: Parent/ItsChild/TheGrandChild

A single location step has three parts:

• an axis, which specifies the tree relationship between the nodes selected by the location step and the context node,
• a node test, which specifies the node type and expanded-name of the nodes selected by the location step, and
• zero or more predicates, which use arbitrary expressions to further refine the set of nodes selected by the location step.

MForm XPath implementation provides a possibility to use unions in location steps. The union is noted as a | between single location steps. All location steps constituting the union should be inside round brackets:
(SingleLocationStep | OtherSingleLocationStep | EvenDifferentLocationStep)

The unions may be used only between location steps, not between parts of location paths.

Example 8

To find all attribute controls and the "AlsoMe" element control of the "Parent" control, located under the control that we run the path, use the following xpath:

Parent/(@* | AlsoMe)

Example 9

To find all controls whose parents are called "Mommy" or "Daddy", use the following xpath:

//(Mommy | Daddy)/*

It is worth mentioning that an output of the MForm XPath Select extension method is an IEnumerable<OffspringItem> controls, which further can be refined using the LINQ query (this is the most important reason why predicates are barely implemented in MForm, they can simply be done with LINQ).

Example 8

Assume that we have a "sampleRoot" MForm Root control and we want to find all the item controls with a value equal "true" and are the children of the "Flags" MForm control.
This code will not work:

sampleRoot.Select("//Flags/*[. = 'true']")

because value predicate is not implemented with MForm XPath. However, the same thing can be implemented like this:

sampleRoot.Select("//Flags/*").Leafs().Where(leafItem => leafItem.Value == "true")
(Leafs() is an extension method that does exactly the same as OfType<LeafItem>())

Of course the second query is longer, but on the other hand all steps are easier to follow (first take only leaf items, because only them can have values, then check the values) and what is more important, we get the actual control and can check all of its properties (also having intellisense checking, etc.).

Example 9

LINQ and MForm XPath can be combined in a manner where there is more than one XPath query.

Let's assume that we have a "clientsRoot" MForm Root control for providing many clients data. This control may have the following tree structure:

• Clients
  • Client (1 to many)
    • FirstName
    • Surname
    • Adresses
      • Address (1 to many)
        • Street
        • City

Now we want to find all the "Client" controls, that represent Mr. Jones, whose all addresses are in the city of Jonestown.

clientsRoot.Select("//Client").Where(
    client => 
        client.Select("Surname").Leafs().Where(surname => surname.Value == "Jones")
        &&
        client.Select("Addresses/Address/City").Leafs().All(city => city.Value == "Jonestown")
);