Symphony.

hey team,

Is there a specific reason for not XSLTProcessor->registerPHPFunctions() to allow for executing php in the transformation? I assume the rationale is to encourage extension development, but I'm holding off on that until the RC1 API. I'm going to break something bad if I put this in?

Thanks

Generally it's a good idea to keep them separate since by using PHP functions your XSLT looses its portability. Perhaps instead you could try using the EXSLT functions, which are available in most XSLT processors: http://www.exslt.org/exsl/index.html

Ok, I've revisited this and I've decided that any portability I lose in the XSL will be made up in the bigger picture; I want to put together a function to replace document() that will allow for constructing proper REST requests.

Does anyone know if there is any way to do this other than just hacking it in there, or otherwise have ideas about how to implement this?

I'm revisiting this idea. Looking at the xsltprocess class, am i correct in concluding that I cannot extend xsltprocss->process() in the context of an extension?

Alternatively, I can just create my own branch at Github with registerPHPfunctions called, correct?