Re: [xslt] patch - python bindings for extension elements

[Daniel Veillard <veillard redhat com>]

On Wed, Jul 09, 2003 at 12:53:34AM +0200, Sean Treadway wrote:
> Attached is a patch of the libxslt-1.0.30 source which contains the
> modifications needed to callback into python for extension element
> binding. (Should patch against 1.0.31 too)
> 
> Thanks a ton for completing the function binding. I based most of the
> code off of that.

  Okay, looks good, I applied it. I just had to modify the generator
to not create bindings to the functions from the module transform,
it was generating methods like "def if(self, node, inst, comp):" clashing
with Python reserved identifiers...

> Issues and oddities:
> 
> * Type wrapping
> 
> 	I followed the example in libxslt.c for wrapping the
> 	xsltElemPreCompPtr.  Given that I am not entirely clear on the
> 	role of this object, I didn't touch the semantics behind it, only
> 	wrapped the pointer to act as a placeholder. `
> 	Shouldn't these type wrappers go in types.c?

  Hum, basically types.c is imported from libxml2 python bindings, so
it's better to keep them separate.

> 	What is the role of xsltElemPreCompPtr?

  Basically, it's an object resulting of the compilation of one of the
stylesheet elements. See 
    http://xmlsoft.org/XSLT/internals.html#XSLT1

> 
> * Returning from callbacks
> 
> 	What should the behavior be when returning failure from the
> 	callback methods?  Right now results are ignored.

  The failure should be indicated by changing the transformation
context error state and generating an error message.

> * Recommended method of packing python tuples
> 
> 	PyTuple_SetItem steals object references, which bit me in the
> 	butt.  Use Py_BuildValue instead.
> 	
> 	http://www.python.org/doc/current/api/refcountDetails.html#l2h-13
> 
> 	I haven't touched the functionality of
> 	libxslt_xsltRegisterExtModuleFunction but I saw somewhere you
> 	mentioned there was still a bug.  If you're seeing segfaults then
> 	refcount bugs could be coming from your argument creation.

   Okay, if you know how to fix this, please do, I take patches :-)
Checking with Stéphane Bidoul would be nice so that at least 2 persons
understanding the bindings verified the changes.

> * Super minor cleanup
> 
> 	I removed some unreferenced variables and initialized some pointers.
> 
> 	Fixed the bug found also in the libxml2 python wrapper regarding
> 	PyFile checking.

   Seen that, it's fine.

> * New python api declaration + generate.py
> 
> 	I get some strange behavior when running generate.py.  I haven't
> 	debugged the generation process, but these methods appear in my
> 	class list during generation which don't show up in the 1.0.30
> 	libxsltclass.txt distribution.  Is it related to my modification
> 	of libxslt-python-api.xml?

   yes and no. You added support for the Precomp type, so a bunch of new
function can be processed and turned into class methods by the generator as
a result.

> 	I get around this by deleting the following lines from my
> 	libxsltclass.txt file before making the python module.

  Better way it to avoid generating bindings for functions from module
transform, at least it's the trick I used ATM.

> 	Also, I think it's a bit ugly that one has to "cast" the incoming
> 	PyCObjects to usable ones (ctxt to transformCtxt).  This should be
> 	done in the wrapper.  

   Hum, does this imply that existing code must change ? I'm not against
improving the bindings but I would rather not break existing code. Please
give some examples, thanks ....

> Now to putting this into use!  

  The example being part of the regression tests now, can you make sure
it only prints "OK" on success ? Just seraching for the extension string
in the list of extensions and comparing the output of the transformation
instead of sending to stdout should achieve that easilly.

> However, I've made a little test case with nested extension elements.
> Obviously, only my outer element gets transformed first because it
> doesn't continue the processing of its elements.  What do I need to
> call to process the contents of the extension element before actually
> doing the custom processing? 

  Hum, that would require calling xsltApplyTemplates() from transform.c
but since the element has not been compiled there is no 
xsltStylePreCompPtr and this may get a bit messy to set up properly,
this need the creation of a empty one (i.e. the select is NULL), not
that hard but would require a bit of work... And extension function
for python operating with a static zeroed xsltStylePreComp might work.

Daniel

-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard@redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/