Symphony.

I'd like to have something like /utilities/ that's like /php-functions/ that can be called from XSLT in emergency situations.

This is when you could use the EXSL Function Manager extension.

See my example for exposing PHP's sha1 function. A totally legitimate and incredibly useful use for exposing PHP in your views.

An alternative to the EXSL Function Manager involves registering PHP functions using an event.

The possibility to throw in some php wouldn't hurt.

I disagree here. The point of XSLT being a 'templating' language is to isolate that 'view' stage from MVC. If you need to use PHP, then you should be doing it at the datasource level.

since the step to custom datasources seems big to me (at least from this side, having not taken it :), even that I know php.

I thought this for a very long time. Until the API came out officially, now I've done a few datasources, and I have to say, it's not as hard as I thought, so I'll just say, jump in and try.

Like Jonas, I fell in love with Symphony for being Symphony, and then after staring at XSL in disbelief for a while, I fll in love with that, once I clicked on how it worked (over PHP that I'm used to). It all just seems right to me.

Once you've learned how to utilise XSLT to its fullest potential you start to realize that it's concept has been so very well thought through and that it is applicable to so many more problems besides the day-to-day ones.

For example given the content (the markup you've written your text in) is valid XML, you can pull additional info from it or transform it into something entirely different right within the same language and following the same procedures as you were transforming the rest in.

Or the fact that XSLT itself is written in XML, thus being transformable and templatable itself. I have simply yet to find any other templating language that is as much concluded and well-defined as XSLT.

To me, templating languages don't have to be "up to date" or "really easy 95% of the time" but must be powerful enough to deal with whatever weird edgecase I throw at it. Only then I can trust it to not be suddenly stretched to it's limits one day. That's what "future proof" is to me.

It just so happens that XSLT is actually pretty easy 95% of the time, too. It just takes a bit of learning and yes, you'll whirl up a little bit of dust while you do so. :-)

As time goes on, wouldn't tiny annoyances/problems just snowball into something unmanageable?

As many have already noted, they are few and far between. And for those that do exist in the real world, there are quick and easy solutions to overcome them.

@Shaw, I hope you realize that all these comments are not because everyone here is a die hard XSLT fan, but rather die hard fans of what works.

Thanks for asking the question and bringing out what I imagine is an elephant in the room.

Or the fact that XSLT itself is written in XML, thus being transformable and templatable itself.

So you could apply XSLT template A to XSLT template B before having the transformed XSLT template B applied to some source XML? If you needed to do that within Symphony (I can't think why you might right now), I suppose you could create a data source that auto-imports template B.

Totally off topic and certainly not a common use-case, but imagine a website that takes in a Symphony section schema and automatically generates XSLT templates for users to plug into their website. The website will store commonly used XSLT template snippets in an XML text area, which is then loaded up by a data source (it's all XML anyway), then modified before it's outputted for the users to cut/paste or download.

So you could apply XSLT template A to XSLT template B before having the transformed XSLT template B applied to some source XML?

Definitely, yes. You could also write your very own templating language like the one I made a few weeks ago.