The ("stable") element type itself.
The ("stable") element type itself. It is not restricted in the query API traits (only indirectly, through ThisElemApi).
Concrete element classes will restrict this type to that element class itself.
Why do we need 2 type members ThisElem and ThisElemApi and not just ThisElem? Consider for example query method implementations in trait ElemLike. Had we used just one type member ThisElem (restricting it to be a sub-type of ElemLike), then a call of a function like findAllChildElems on another element would not return a value of the same type (ElemLike.this.ThisElem) according to the Scala compiler. To prevent the use of casts, we used 2 type members ThisElem and ThisElemApi instead.
Upperbound on type ThisElem, which must be restricted to a sub-type of the query API trait in question.
Upperbound on type ThisElem, which must be restricted to a sub-type of the query API trait in question.
Concrete element classes will restrict this type to that element class itself.
The purely abstract query API traits (XXXApi) should only restrict this type to a sub-type of the query API trait, without putting any further restrictions on the type. This way these purely abstract traits are easy to use as "generic" element contracts abstracting over multiple backing element implementations (for example, Saxon tiny trees and native yaidom elements) without "infecting" the client code with generics.
To a lesser extent, this should also be true for the partially implemented query API traits (XXXLike).
Returns all child elements paired with their path entries.
Returns all child elements paired with their path entries.
Finds the child element with the given Path.Entry (where this element is the root), if any, wrapped in an Option.
Finds the child element with the given Path.Entry (where this element is the root), if any, wrapped in an Option.
Typically this method must be very efficient, in order for methods like findElemOrSelfByPath to be efficient.
This element itself.
This element itself.
Finds the element with the given Path (where this element is the root), if any, wrapped in an Option.
Finds the element with the given Path (where this element is the root), if any, wrapped in an Option.
That is, returns:
findReverseAncestryOrSelfByPath(path).map(_.last)
Note that for each non-empty Path, we have:
findElemOrSelfByPath(path) == findChildElemByPathEntry(path.firstEntry) flatMap (e => e.findElemOrSelfByPath(path.withoutFirstEntry))
Finds the reversed ancestry-or-self of the element with the given Path (where this element is the root),
wrapped in an Option.
Finds the reversed ancestry-or-self of the element with the given Path (where this element is the root),
wrapped in an Option. None is returned if no element can be found at the given Path.
Hence, the resulting element collection, if any, starts with this element and ends with the element at the given Path, relative to this element.
This method comes in handy for (efficiently) computing base URIs, where the (reverse) ancestry-or-self is needed as input.
Returns (the equivalent of) findChildElemByPathEntry(entry).get
Returns (the equivalent of) findChildElemByPathEntry(entry).get
Returns (the equivalent of) findElemOrSelfByPath(path).get
Returns (the equivalent of) findElemOrSelfByPath(path).get
Returns (the equivalent of) findReverseAncestryOrSelfByPath(path).get
Returns (the equivalent of) findReverseAncestryOrSelfByPath(path).get
API and implementation trait for elements that can be navigated using paths.
More precisely, this trait has only the following abstract methods:
findChildElemByPathEntryandfindAllChildElemsWithPathEntries.The purely abstract API offered by this trait is eu.cdevreeze.yaidom.queryapi.IsNavigableApi. See the documentation of that trait for more information.