Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Resolve includes/imports #19

Open
seanmcilvenna opened this issue Jul 30, 2015 · 3 comments
Open

Resolve includes/imports #19

seanmcilvenna opened this issue Jul 30, 2015 · 3 comments

Comments

@seanmcilvenna
Copy link

If my xslt/xml files are stored in a DB, is it possible to customize the include/import resolution of XSLT files so that I can pass the XSLT's requested includes from the database.

Pseudo example:

xslt.resolver = function(fileName) {
var buffer;
// read file content into buffer from DB
return buffer;
}

@albanm
Copy link
Owner

albanm commented Nov 19, 2015

I think libxslt has some mechanisms for these kind of things. But I suspect it would be quite complicated and honestly I have no plan to look into it soon.

Of course as usual, a pull request would be very welcome.

@neu-rah
Copy link
Contributor

neu-rah commented Nov 20, 2015

you can load your xslt file as a xml document, xpath into it to find your special includes and do in-place replacement.
guess you know that, and i agree it would be nice to be automatic but its complicated for sure

@gagern
Copy link
Collaborator

gagern commented Nov 20, 2015

There are two possible hooks which could be used for this: xsltDocLoaderFunc (implemented in xsltDocDefaultLoaderFunc) or the one set by xmlSetExternalEntityLoader (with default implementation xmlDefaultExternalEntityLoader). The former is in libxslt and has to return a parsed document, while the latter is in libxml and has to return a pointer to an xmlParserInput structure. The default file access seems to go through xmlNewInputFromFile which doesn't seem to provide a hook.

Note that the function pointer variables used for both the hooks described above aren't thread-local, so we can't set it per stylesheet, but would have to set it for the whole process. We could of course replace it with a small function which examines some thread-local varibale and delegates to the default implementation (which is static but which can be read from the xsltDocDefaultLoader variable resp. retrieved using xmlGetExternalEntityLoader) if no thread-local override was found. See occurrences of tls in libxmljs.cc for an example of thread-local storage.

If we hook in with the xmlParserInput structure, should we be gluing that to a Buffer, or would it be more appropriate to follow the node stream API? Or perhaps both, at least in the long run? Buffers are certainly easier since we don't need to block and wait for another thread in the xmlInputReadCallback implementation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants