Hi lxml-developers, I have another question about the way lxml handles namespaces in combination with Python based elements: Think of an example derived from the doc/namespace_extension.txt from lxml.etree import Namespace, ElementBase namespace = Namespace('http://hui.de/honk') class HonkElement(ElementBase): def __str__(self): return 'String of this element' tree = XML('<a><b><c><honk xmlns="http://hui.de/honk" honking="true"/
</c></b></a>')
The question is: is it possible to make the tree build to xml by using lxml.etree.tostring(tree) where during the evaluation the __str__ (or another method) of the Python element is called. Otherwise the example as given in the doc will only work when the Python element is root of a tree as in: honk_element = XML('<honk xmlns="http://hui.de/honk" honking="true"><a><b/></a></honk>') Kind regards, Petr van Blokland ---------------------------------------------- Petr van Blokland buro@petr.com | www.petr.com | +31 15 219 10 40 ----------------------------------------------
Hi Petr, Petr van Blokland wrote:
Think of an example derived from the doc/namespace_extension.txt class HonkElement(ElementBase): def __str__(self): return 'String of this element'
tree = XML('<a><b><c><honk xmlns="http://hui.de/honk" honking="true"/
</c></b></a>')
The question is: is it possible to make the tree build to xml by using
lxml.etree.tostring(tree)
where during the evaluation the __str__ (or another method) of the Python element is called.
No. As I said before, elements are never 'executed' by lxml. Remember that lxml builds on top of libxml2, so things like serialisation, XSLT, XPath or validation run entirely in C. While there are ways to hook into XPath and XSLT for extension functions (and elements, btw), there is no way to hook into validation or serialisation. However, I still think it is worth looking at the current Namespace mechanism and seeing if there are other interesting things we can do with it. The function registration, for example, unified and simplified the API towards extension functions. XSLT elements are an obvious step forwards, although the API is far from clear to me. What you proposed in your last mail is viable, but only a special case. It misses the support for XSLT subtrees below the extension element, for example. I also thought about an extension towards a more XIST-like API for creating trees, like el = html( head(title("title"), body(p("test paragraph"), "more text") ) but I found that that's not trivial either. One reason is that we can't easily call "title()", i.e. without arguments, as we use that internally for normal element construction. So, there are a lot of interesting paths to follow here, but I haven't sorted out yet how to get this nicely integrated (and implemented). You seem to have some good ideas, so if you want to discuss them further, here's the place to do it. :) Stefan
participants (2)
-
Petr van Blokland -
Stefan Behnel