Re: [xslt] extension modules

[Thomas Broyer <tbroyer ltgt net>]

Le 22/07/01 16:54:36, Daniel Veillard a écrit :
> > Here's a list of some of the changes:
> >   · added function lookup framework to libxml/XPath and used it in
> >     libxslt and modified the extension element lookup in the same way
> >     (look for the element in the context, then in the global registry)
> 
>   Not sure I understand this one. can you give me the names of the
> functions ?

 /*
  * Function Lookup forwarding
  */
typedef xmlXPathFunction
       (*xmlXPathFuncLookupFunc)       (void *ctxt,
                                        const xmlChar *name,
                                        const xmlChar *ns_uri);
 
void   xmlXPathRegisterFuncLookup      (xmlXPathContextPtr ctxt,
                                        xmlXPathFuncLookupFunc f,
                                        void *funcCtxt);

libxslt registers its own lookup function to also look for extension module
functions in the global hash table.

>   Everything else sounds fine. 

Great ;o)

> > What's still needed:
> >   · correct handling of extension-element-prefixes and
> >     exclude-result-prefixes. extension-element-prefixes may need
> >     binding data to the _private field of *every* element node (even
> >     literal result elements)
> 
>    Hum, that part is complex. Tell exactly what you need and I will
> check.
> I took great care of not destroying performances to handle those and this
> requires a lot of attention to get right.
>    In general if you start adding data or processing for each node at
> run time then thwin twice and ask first :-)

Well, I'm not sure what's really needed...
Maybe extension-element-prefixes can be handled the same way
exclude-result-prefixes are handled, since we'll precompute extension
elements.
I'll look at it in details...

Actually, I was thinking of making a stripped down version of
xsltStylePreComp and adding 2 types: extension element and literal result
element. Extension elements could then extend this struct with their own
precomputed data, and -- most important -- associate a callback function to
process the node.
There are 3 things that can justify that:
 · if extension-element-prefixes, and maybe exclude-result-prefixes,
   handling needs some data bindings at node level
 · extension elements have a way of adding precomputed data:
   the stylesheet is a bit more homogeneous, and -- most important --
   the struct can carry a free() function. This way, the _private
   field can be used without memory leak or hackish "registration" of
   computed data to be freed by the module's shutdown function (something
   similar to the preComps field of xsltStylesheet, that any module
   implementor would have to mimic) If I'm not clear enough, I can provide
   a better, longer explaination ;o)
 · the callback function for extension elements can be attached to the
   node instead of being looked up for each transformation

If the first point isn't needed, literal result elements do not need
precomputed data.

Processing of an element would then consist only in calling _private->func
(or check whether its a literal result element -- _private is NULL -- and
then copy the node or call _private->func ; if the first point above is not
needed)

This may improve performances of transformations (more things are computed
during preprocessing)

Also, extension elements now consist only in a precomp function, and its up
to this function to set the {precomp}->func => no need to look up the
transform function in a hash table any more => better performances (maybe
its peanut, I don't know...)

Just an idea...

Tom.