[lxml-dev] Context of custom XPath functions

[Frederik Elwert]

Hi,

Am Freitag, den 24.08.2007, 00:05 +0200 schrieb Stefan Behnel:
> I investigated this a little. It looks like such a context is not as hard to
> implement as I first thought. We can just throw an exception for the dangerous
> cases for now, so that we can see if people actually use them. And since the
> pointer to the libxml2 XPath context is cleared before returning from the
> function, we can determine the case where users keep the context alive and
> just throw an exception as well.

That sounds good!
> 
> Frederik Elwert wrote:
> >       * a node (the context node)
> 
> We can instantiate the context Element if it's from the current document, that
> should not do any harm.

That's the major point, I think.

> >       * a pair of non-zero positive integers (the context position and
> >         the context size)
> 
> libxml2 makes them available, but since I don't quite get what they are used
> for, I'll leave these out for now. (Feel free to convince me that they are
> needed).

No, I totally agree. I just wanted to see how XPath defines the context
here. But I wouldn't know for what to use this information.

Same for the next points...
> 
> >       * a set of variable bindings
> 
> We can get these from libxml2's XPath context by traversing a hash table.
> However, I'm not sure how these behave for XSLT, so I'll also just leave these
> out for now.
> 
> 
> >       * a function library
> 
> Who cares, really? Just call another XPath expression if you really need to
> access an XPath function.
> 
> 
> >       * the set of namespace declarations in scope for the expression
> 
> That's just the nsmap of the context node.
> 
> libxml2's XPath context also has a pointer for the value of the here()
> function, maybe that's interesting, too.

Erm, I just have no idea what the here() function provides, so I can say
that I don't need it for now... :-)

> Ok, so I think it would be enough for now to provide the context with a
> property "context_node" and maybe with a call-local dictionary that allows
> functions to keep state.
> 
> Would that be enough for you?

Definitely. Thanks for all the investigations.

> BTW, this is definitely lxml 2.0 stuff, it won't go into lxml 1.3.

Sure. I have a working solution for now. But I really think this is a
good and powerful thing to have, so I'll be looking forwards to lxml
2.0!

Thanks again,
Frederik