[lxml-dev] XInclude support
Hi there, I've enabled simple XInclude support. If you call the new .xinclude() method on a document, it will proceed with XInclude processing. If people are interested to test this, let me know how it works out. Regards, Martijn
On May 21, 2005, at 12:49 PM, Martijn Faassen wrote:
Hi there,
I've enabled simple XInclude support. If you call the new .xinclude () method on a document, it will proceed with XInclude processing. If people are interested to test this, let me know how it works out.
No, no, noooooo! Err, yes! :^) I just wrote down this morning how I was going to rewrite my stuff to work around the missing XInclude support in a simpler fashion. Fortunately I hadn't implemented it yet. This is *perfect* timing, thanks a *bunch*! BTW, I had pretty good luck yesterday with XSLT parameters. I did both the string and XPath. About the only thing I can complain about is really petty and trivial: support for None. The basic pattern is this: let's say I might or might not pass in a parameter which I grab from in the process of doing something. Instead of: if viewarg: result = style.apply(doc, viewarg=viewarg) else: result = style.apply(doc) ...it would be nice to say: viewarg = None result = style.apply(doc, viewarg=viewarg) When you several things to pass in, the combinations of testing will get pretty crazy. I realize there might be some Pythonic way to do this that avoids the need of supporting None. In the course of doing this, I found (I think) that the error reported when something is wrong with your parameters is a bit misleading. IIRC, it was NameError: XSLTApply or something. --Paul
On 5/21/05, Paul Everitt <paul@zope-europe.org> wrote:
if viewarg: result = style.apply(doc, viewarg=viewarg) else: result = style.apply(doc)
...it would be nice to say:
viewarg = None result = style.apply(doc, viewarg=viewarg)
No; you expecting lxml to assign semantics to missing values from your application, which is wrong. Try this instead: kw = {} if viewarg: kw["viewarg"] = viewarg result = style.apply(doc, **kw) This keeps understanding of parameter values where it belongs: in the application that provides them. -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> Zope Corporation
On May 21, 2005, at 2:45 PM, Fred Drake wrote:
On 5/21/05, Paul Everitt <paul@zope-europe.org> wrote:
if viewarg: result = style.apply(doc, viewarg=viewarg) else: result = style.apply(doc)
...it would be nice to say:
viewarg = None result = style.apply(doc, viewarg=viewarg)
No; you expecting lxml to assign semantics to missing values from your application, which is wrong. Try this instead:
kw = {} if viewarg: kw["viewarg"] = viewarg result = style.apply(doc, **kw)
This keeps understanding of parameter values where it belongs: in the application that provides them.
Yep, just what I needed. Thanks Fred! --Paul
Paul Everitt wrote: [snip]
BTW, I had pretty good luck yesterday with XSLT parameters. I did both the string and XPath.
[snip]
In the course of doing this, I found (I think) that the error reported when something is wrong with your parameters is a bit misleading. IIRC, it was NameError: XSLTApply or something.
Thanks for testing this. Hey, I thought I fixed this NameError, I even have a test for it, can you still get this with recent checkouts? You do get an XSLTApplyError that's singularly uninformative if you do something wrong with parameters. This is part of a general problem right now with lxml and error handling. I brutally suppress all libxml2 errors, as it otherwise it tends to spam you to death. In fact, my brutal surpression isn't fully effective as it still tends to spam you when you start up another thread (but I know that's fixable, just haven't gotten around to it). What in fact needs to happen is some clever interfacing with libxml2 so that its frequently useful output is caught and presented to the programmer in some fairly nice way that works well with Python. What that should be, and what the details of such interfacing with libxml2 would look like, I'm not entirely sure about yet. It will be a fairly involved project to start tackling this, though hopefully straightforward enough to write once I or someone else figures out the basics. Regards, Martijn
Martijn Faassen wrote:
Hi there,
I've enabled simple XInclude support. If you call the new .xinclude() method on a document, it will proceed with XInclude processing. If people are interested to test this, let me know how it works out.
Hey, Looking at some ElementTree test cases I realized that ElementTree already has an API for xinclude support, when reading a document. I need to evaluate whether we want to switch to this API, or add it in addition. I do like the pattern of having an .xinclude() method next to the xpath(), relaxng() and xslt() method on the tree object. :) Regards, Martijn
participants (3)
-
Fred Drake -
Martijn Faassen -
Paul Everitt