Re: [xslt] Release of libxslt-1.1.26
- From: Stefan Behnel <stefan_ml behnel de>
- To: xslt gnome org
- Subject: Re: [xslt] Release of libxslt-1.1.26
- Date: Mon, 28 Sep 2009 09:29:23 +0200
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
[
Date Prev][Date Next] [
Thread Prev][Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]