For selecting properties arbitrary XPATH expressions can be used, which select single or multiple configuration nodes. The associated {@code Configuration} instance will directly pass the specified property keysinto this engine. If a key is not syntactically correct, an exception will be thrown.
For adding new properties, this expression engine uses a specific syntax: the "key" of a new property must consist of two parts that are separated by whitespace:
"/tables/table[1] type"
This will add a new {@code type} node as a child of the first {@code table}element.
"/tables/table[1] @type"
Similar to the example above, but this time a new attribute named {@code type} will be added to the first {@code table} element.
"/tables table/fields/field/name"
This example shows how a complex path can be added. Parent node is the {@code tables} element. Here a new branch consisting of the nodes{@code table}, {@code fields}, {@code field}, and {@code name} will be added.
"/tables table/fields/field@type"
This is similar to the last example, but in this case a complex path ending with an attribute is defined.
Note: This extended syntax for adding properties only works with the {@code addProperty()} method. {@code setProperty()} does not supportcreating new nodes this way.
From version 1.7 on, it is possible to use regular keys in calls to {@code addProperty()} (i.e. keys that do not have to contain a whitespace asdelimiter). In this case the key is evaluated, and the biggest part pointing to an existing node is determined. The remaining part is then added as new path. As an example consider the key
"tables/table[last()]/fields/field/name"If the key does not point to an existing node, the engine will check the paths {@code "tables/table[last()]/fields/field"}, {@code "tables/table[last()]/fields"}, {@code "tables/table[last()]"}, and so on, until a key is found which points to a node. Let's assume that the last key listed above can be resolved in this way. Then from this key the following key is derived: {@code "tables/table[last()] fields/field/name"} byappending the remaining part after a whitespace. This key can now be processed using the original algorithm. Keys of this form can also be used with the {@code setProperty()} method. However, it is still recommended touse the old format because it makes explicit at which position new nodes should be added. For keys without a whitespace delimiter there may be ambiguities. @since 1.3 @version $Id: XPathExpressionEngine.java 1624601 2014-09-12 18:04:36Z oheger $
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|