Re: tree fragments

[<php...@li...>]

Ah good.  So the new mail list is working :o)

> Last week was a bit busy for me and I didn't get a chance to mention the
> things on my mind, so here goes.
>
> Would it be possible to be able to create a result tree fragment and then
> insert that result tree fragment into the XML tree.  In particular, I am
> refering to something similar to the javascript xmldom.  You do something
> this...
>
> create element
>   -> create attribute
>   -> add text
>
> then take that, and insert it into the tree....the only reason I would
want
> to do something like this is because I imagine it would be faster than
having
> to access the whole tree at once while continuously adding data to the
same
> node...or am I wrong in thinking that?

DOM specifies that you can appendChild(Node), but a Node can be a
DocumentFragment.  This maps for us to an XmlString as opposed to a node
name.  So I'd imagine that in the future we will move to appendChild()
taking an xmlString instead of a node name, and it will append the xml
portion to the given node.

This would allow:

appendChild('/root[1]/users[1]',
'<user><name>Nigel</name><country>Scotland</country></user>')

So yeah, this is in the pipeline.

> Secondly, I remember reading in the changelog that all DOM functions can
> accept a single node xpath...such as
>
> $xmltree->appendChild("/root","newnode");
>
> however, when I do the above, without the "[1]" at the end of root, I get
an
> error that the node does not describe a unique node in the tree, even
though
> I only have one root tag.  Perhaps this is just a bug?

This is the first big issue that every Php.XPath user tends to find....
/root is a bad example (as there can only be 1 root), but suppose you have
xml that looks like:

<root>
    <element/>
</root>

Now /root/element describes exactly 1 node, but suppose you then
appendChild('/root[1]','element') you'd get:

<root>
    <element/>
    <element/>
</root>

Now /root/element no longer describes 1 node but 2.


So, when the interface takes a parameter of $absoluteXPath, you must provide
the ABSOLUTE path to the node, ie fully qualified, not just a search that
contains 1 node.


Some of the functions allow you to use an XPath expression, others don't.
We're in the process of upgrading all the calls to take an XPath expression
and if it isn't an absolute XPath, it is evaluate()'ed then the function is
applied to all the nodes.  Sadly this may -sometimes- make the calls much
slower, as it will have to make a call to evaluate(), but it will make the
class a whole lot easier.

So you've not found a bug, but you've found an area that is on the plan for
being addressed in future releases.

Cheers all,

Nigel