Hi Darren.
I agree that it is very useful to take a path. The proposal you laid
out looks good. I suggest an addition, based on a useful feature of
ManifestServ: the ability to add values to the search, to narrow it down.
Suppose you have two elements of type X, one with value 1 and one with
value 2, and you want to retrieve the value of //X/Y but only for the
second X element. Something like //X=1/Y could specify this. (Pretty
sure that Xpath has a way to specify this kind of thing, though I don't
know it off hand.)
With the nested for loops, one could inspect and prune along the way
manually. get_path() removes this inspection capability. Adding a way
of specifying values in the path itself provides a convenient way to
restore this capability.
Thanks,
Jack
On 07/29/10 05:42 AM, Darren Kenny wrote:
Hi,
Due to the directions some projects have taken (e.g. DC and finalizer scripts)
the DOC needs a new feature to allow for people to refer to the contents of the
DOC by a Path. This both allows for a simpler way to handle the finalizer case,
and in our own code, to allow for people to write:
ret = doc.get_path("//xxxxx/xxx/x.y")
# Do something with return values.
rather than
ret = list()
for desc in doc.get_descandants("xxxxx")
for child in desc.get_children("xxx"):
for child2 in child.get_children("x")
ret.append(child2.y)
# Do something with return values.
DC requires this to support finalizer scripts which can be called using
parameters specified in the XML manifest.
The entry in the manifest would contain a command to be run, with
specific elements of the DOC to be extracted using %{} references like:
my_finalizer.sh %{//target_dir}
which would look for something in the DOC, mapping a call like this to:
doc.get_descendants(name="target_dir")
other mappings would be :
/ => get_children()
First '/' would be the DOC itself (root)
// => get_descendants()
@type => A class type for 'class_type' parameter
#num => Max count (matches)
?num => Max depth (with //)
.attr => An attribute of a matched object - always at the end of the
path - got via getattr (but would omit '_' prefixed attrs).
The DOC would return a list of matches to the criteria - DC can then
decide how to pass to the command - e.g.:
- Quoted Arguments
"match1" "match2" ...
- Comma (or similar separated)
"match1,match2"
If no match is found, the usual ObjectNotFound exception will be raised, or if
the attribute you request doesn't exist, then an AttributeError wil be raised.
Does this proposal work for people - I will eventually add this to the DOC
design document, but I would like to get feedback before I do, rather than going
through a full review of the DOC design document again.
Thanks,
Darren.
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
