IsNavigableApi
Related Docs:
object IsNavigableApi
| package queryapi
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.
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.
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) findElemOrSelfByPath(path).get
Returns (the equivalent of) findReverseAncestryOrSelfByPath(path).get
This element itself.
This element itself.
This trait offers Path-based navigation support.
This trait typically does not show up in application code using yaidom, yet its (uniform) API does. Hence, it makes sense to read the documentation of this trait, knowing that the API is offered by multiple element implementations.
This trait is purely abstract. The most common implementation of this trait is eu.cdevreeze.yaidom.queryapi.IsNavigable.
IsNavigableApi more formally
Some properties are expected to hold for "navigable elements":
getElemOrSelfByPath(Path.Empty) == self findElemOrSelfByPath(path1).flatMap(e => e.findElemOrSelfByPath(path2)) == findElemOrSelfByPath(path1.append(path2))