Symphony.

What do you guys think about integrating XSLTProcessor::registerPHPFunctions into Symphony? It would provide a way to use more custom and flexible functions in XSL-Templates. Of course on the downside the templates would be incompatible with non-PHP-based XSLT processors (basically all of them).

Unfortunately there is no delegate in the XSLT processor wrapper so this functionality can’t be put in an extension for now.

This seems like a good idea and could possibly help with adoption.

I don’t think that it would matter about the templates, although I can see it leading to some ‘ugly’ results.

For now, it’d be nice to easy access to things like explode, implode and regex without having to use separate utilities/not at all.

I’m keen on this for the regex support but nothing more — in an MVC architecture ideally all controller/business/flow logic would sit in the controller (Data Sources) and not the views (Pages) and PHP functions could begin to blur the lines somewhat.

Perhaps this could be an option in the config (yes/no) which advanced users could enable should they wish to use them?

Is there any documentation on performance?

I’m keen on this for the regex support but nothing more

Same here :-)

I’d certainly like to have access to PHP functions from within Symphony templates. Perhaps it’s because I’m not an XSLT guru but I do find it very frustrating at times to achieve relatively simple action in PHP in XSLT.

Perhaps this could be an option in the config (yes/no) which advanced users could enable should they wish to use them?

I like this idea, alongside a way of specifying which functions you want available would be nice.

This is a tricky one as it may undermine the whole point of XSLT. If certain types of functions open up the ability to modify data or grab data outside of XML, it really sidesteps the fundamental development philosophy behind Symphony.

That said, I don’t have a problem to optionally allow certain functions that is already available to XSLT 2.0 (i.e. Regex, implode and explode) – this can be seen as a stop-gap solution until LibXSLT supports XSLT 2.0.

Before I got sidetracked by paying work, I was working on an extension to allow this. However, the problem was that there was no delegate in the appropriate spot, so the extension was actually creating a new XSLTProcessor object which then transformed the XML doc, then feeding that and a hardcoded ‘pass-through’ xsl doc to Symphony’s built-in processor. Obviously there were problems of efficiency, as well as totally borking the debug extensions.

Rather than totally opening the floodgates to any php function, I would suggest actually making a RegisterPHPfunctions delegate. This way, Symphony extensions could register php explicitly, and possibly have their own namespaces in the xsl.

I’m excited about this idea, b/c it could open the door for making full RESTful HTTP requests through XSL.

Actually, I am quite certain you can already do this. Subscribe to the FrontendOutputPreGenerate or FrontendPreRenderHeaders delegates, and use the following code:

Frontend::instance()->Page()->Proc->registerPHPFunctions();

I think that will do what you’re after.

I should mention, if the above code doesnt work, you can instead use the $page variable provided by the FrontendOutputPreGenerate delegate. E.G.:

$context['page']->Proc->registerPHPFunctions();

Hmm, doesn’t seem to work. Think it needs to be called on the XsltProcessor instance rather than XsltProcess.

eh. stupid. You’re right.

Have a look at this commit in the integration branch. Using the same method as above, but using slightly different code, you should be able to register functions.

Frontend::instance()->Page()->registerPHPFunction('functionX');
Frontend::instance()->Page()->registerPHPFunction('functionY');

or

Frontend::instance()->Page()->registerPHPFunction(array('functionX', 'functionY'));

Nice!

Of course on the downside the templates would be incompatible with non-PHP-based XSLT processors (basically all of them)

I’ve pondered this issue, and there’s no really clean way to handle it. Any way you do, you want to keep your extension functions as separate as possible from the rest of your templates.

One way I’ve considered involves using exslt to wrap your php-specific function calls into generic function calls with their own names/prefixes. This way you avoid having the php namespace in your main templates, and just include a php-specific implementation of the functions in its own document.

If you need to use the XSL in another processor, you would produce an analogous function wrapper for whatever the other processor would be.

In considering this I think it’s worth noting that extension functions (such as the php implementation) are actually allowed in the standard, they just make your code less portable.

@Alistair Nice implementation. I think it’s much better than creating a specific delegate.

Symphony have no limits!