[lxml-dev] Does lxml/libxslt support passing in nodes as xsl:param parameters?
I believe the answer is no. I can't tell if this is part of the spec, but docs on other processors imply that you can use a node or node list as the value of a parameter passed to a transformation. In my use case, I'm trying to get information from the current web request. I don't want to modify the input document (my normal way to do this.) Thus, an XPath extension function or a document resolver will have to serve the purpose. This will be tricky, because I'll have to do a thread local or something to know I'm grabbing a *particular* request. Perhaps I need to ponder this. I must be looking at it the wrong way. I want to make sure I don't reparse the input document (it might be pretty big) nor the XSLT processor. --Paul
Hi, Paul Everitt wrote:
I believe the answer is no. I can't tell if this is part of the spec, but docs on other processors imply that you can use a node or node list as the value of a parameter passed to a transformation.
In my use case, I'm trying to get information from the current web request. I don't want to modify the input document (my normal way to do this.) Thus, an XPath extension function or a document resolver will have to serve the purpose.
XSLT parameters are passed as strings (char*), so passing subtrees will not work. Passing an XPath expression will work, though, so you can at least refer to all sorts of things that exist in the current context. But have you looked at XSLT extension elements? They might do what you want. http://codespeak.net/lxml/extensions.html#xslt-extension-elements Stefan
On Jul 19, 2008, at 2:52 PM, Stefan Behnel wrote:
Hi,
Paul Everitt wrote:
I believe the answer is no. I can't tell if this is part of the spec, but docs on other processors imply that you can use a node or node list as the value of a parameter passed to a transformation.
In my use case, I'm trying to get information from the current web request. I don't want to modify the input document (my normal way to do this.) Thus, an XPath extension function or a document resolver will have to serve the purpose.
XSLT parameters are passed as strings (char*), so passing subtrees will not work. Passing an XPath expression will work, though, so you can at least refer to all sorts of things that exist in the current context.
But have you looked at XSLT extension elements? They might do what you want.
http://codespeak.net/lxml/extensions.html#xslt-extension-elements
My challenge is getting at data that was in scope at the time I ran the transformation. The extension element won't have access to that information. I'll be in a threaded environment (WSGI request), so I'll need to arrange to stash the data away in a thread local, then grab it from within the extension element. Or?? --Paul
Hi, Paul Everitt wrote:
My challenge is getting at data that was in scope at the time I ran the transformation. The extension element won't have access to that information.
Ah, right, extension elements are registered at the time of the XSLT() instantiation, not the call. Although that's not really a strict requirement...
I'll be in a threaded environment (WSGI request), so I'll need to arrange to stash the data away in a thread local, then grab it from within the extension element.
I think that's a feasible option for now. I see two clean solutions to this: 1) make the "eval_context" dict property of the XPath/XSLT context initialisable by use code 2) support passing extensions to an XSLT call (as well as the XSLT instantiation) Both would require changing the XSLT call signature where we currently accept arbitrary keyword arguments. A way not to break code here would be to add the extensions/context dict as an optional positional argument, not as a keyword argument. I prefer option 1), as it's the least intrusive and solves many similar problems without much overhead. I take patches. :) Stefan
participants (2)
-
Paul Everitt -
Stefan Behnel