Stefan Behnel wrote:
Martijn Faassen wrote:
I'm trying to understand why in scoder2 there's the use of _fakeRootDoc in a few places. I imagine this is to work around some bugs that show up in the trunk, but I don't have enough context on what and why. Stefan, can you enlighten me? Any tests that expose this behavior in particular?
[snip]
The drawback is that libxml2 actions that run on ElementTrees now cannot know by themselves which element is the actual root of the ElementTree (which is called _context_node in _ElementTree), as it is no longer the root of the document.
Right, thanks for pointing out this consequence.
This is what _fakeRootDoc is for. It takes an arbitrary element and its document and then temporarily creates a fake copy of the document that has a copy of the element as root. So, while the original element is still in its previously (arbitrary) position, its copy now forms the root of the fake document. (It is necessary to copy it since it must not have any siblings.) libxml2/libxslt actions are then run against that fake document, which is cleaned up (i.e. deleted) immediately after the action.
One little hack is that it only copies the element, it does not do deep-copying. It should therefore be possible to access higher ancestors that are not below the _context_node of the respective ElementTree via e.g. an XSLT (like via <copy-of select="ancestors::node()"/>). I didn't test that, but I believe it is not too bad, since it is a rather rare case and somehow even fits the ElementTree idea of Elements being 'free'.
Hm, this is rather worrisome. I would expect an ElementTree to be a whole document and this could potentially lead to odd effects depending on the way the XSLT engine works -- basically due to this hack, the operation is performed on a tree that is not actually correct and this could lead to all kinds of unexpected behavior... Additionally, how does the getparent() operation fare in this context? The parent of a node that's wrapped directly in an ElementTree might be something that's not even supposed to be in that tree, which is really unexpected. Or is there a reason this doesn't happen?
I know, it might sound a little confusing at first, but I hope you got the idea.
Yes, I think so, thank you for the explanation. I now need to consider costs and gains of this approach compared to the one lxml is taking currently... Regards, Martijn