Daniel Veillard wrote: > A small release fixing a few bugs and exporting xsltProcessOneNode > since deployed lxml use it. Availbale as usual at: > ftp://xmlsoft.org/libxslt/ > > Improvement: > - Add xsltProcessOneNode to exported symbols for lxml (Daniel Veillard)
Thanks, Daniel. I wasn't aware that it was a non-public function when I started using it in lxml. I guess I just looked through the libxslt sources at the time (where it wasn't defined "static"), rather than the header files or the docs, since I was manually tracing the way XSLT execution takes to be able to inject my own code. lxml has a feature that allows you to define a Python class that executes your own code during XSLT processing of an extension element. http://codespeak.net/lxml/extensions.html#xslt-extension-elements To do this, I needed to provide a way to users to apply the regular XSL templates on the subtree, so that their code can actually perform its task at any level of the XSL document tree, even if it has children etc. Thus the call to xsltProcessOneNode. In the Python code, this is hidden behind a method call to the superclass' ".apply_templates(xslt_node)". When I noticed that it wasn't a public function, I actually asked on the libxslt ML but didn't get an answer at the time (I only noticed now that you replied recently). It wasn't high priority for me, since it worked under Linux and also with static builds under Windows and MacOS. Anyway, thanks for making this public. The function seems to work perfectly for the use case at hand. Stefan _______________________________________________ xslt mailing list, project page http://xmlsoft.org/XSLT/ [email protected] http://mail.gnome.org/mailman/listinfo/xslt
