Re: [xslt] patch - python bindings for extension elements
- From: Daniel Veillard <veillard redhat com>
- To: xslt gnome org
- Subject: Re: [xslt] patch - python bindings for extension elements
- Date: Wed, 9 Jul 2003 06:17:39 -0400
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
> * 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.
> 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
> 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 Veillard | Red Hat Network https://rhn.redhat.com/
email@example.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
] [Thread Prev