Symphony.

A new extension, "XSL Resource Loader" is now available for download. Comments and feedback can be left here but if you discover any issues, please post it on the issue tracker.

This is more of a proof-of-concept but the basic gist goes like this: With this extension you don't need to attach your components to your pages using the Symphony pages editor (wich saves the relation somewhere in the database). Instead it lets you save it directly in the XSL itself.

For example the following code loads the Data Source articles and the Event comments and attaches them to the page:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0"
    xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
    xmlns:res="http://getsymphony.com/schemas/resources/1.0"
    exclude-result-prefixes="res">

<res:data-source name="articles" />
<res:event name="comments" />

...

</xsl:stylesheet>

I haven't tried this yet but this concept sound so logical that I ask myself why these information are stored in the database at all.

Two questions:

• Are there any performance implications?
• Is it possible to load resources conditionally depending on page parameters?

That's smart! Maybe you can introduce an additional attribute test or if which is an xpath expression that gets evaluated to a boolean, determining if the resource should be loaded or not.

Are there any performance implications?

Well, the page.xsl is being opened and interpreted by SimpleXML, which then runs two xpath()-matches on the XML. There is no XSL stuff going so the performance setback should be marginal.

Is it possible to load resources conditionally depending on page parameters?

Technically yes, somehow. Although I am not really convinced that mixing View- and Controller-logic would be a good idea. Or is this conditional attachment of Controller/Datasource a core principle of MVC?

I'm not sure I see how that would be possible, because the datasources and events need to be executed before the page template can be processed right? You'd end up with a recursion problem if your xslt logic for loading resources depended on data returned from the same resources...

Very cool idea though, and one that had crossed my mind a few times before, though I never thought of parsing the page xml separately to look for resources; my thought process was to look at what DS names were being attempted to be matched, but that can't really work once you get into advanced xpaths that don't even have the name of the datasource node in them.

This is a great idea! Yet another step forward in our goal of removing as much structure data from the database with the aim of only using the database fro entry data!

Loving it.

because the datasources and events need to be executed before the page template can be processed right?

The impression I get from what @phoque said earlier is that the page is loaded by SimpleXML to get the resources list, the resources are then loaded by PHP, then the template is processed by XSL. It seems to be only a slight change in the current process, but I believe that the proces must be faster than a database call to figure out the resource attachments.

@delegate request :D

A delegate on this line to add more resources? Like Translations provided by Frontend Localisation ...

Think of this as a fork of Global Resource Loader: Right after the page, its URL-params and the regular resources have been resolved the Global Resource Loader gets the chance to inject its own set of resources and append them to the pages resource pool.

This extension does exactly the same but instead of reading the values from config.php it opens the file, looks around in the XML and goes on from there.

So, doing conditionals on URL-params is definitely possible, it would be in a non-XSL-syntax though. I don't think it's really necessary at the moment though; let's see if it is useful at all and go on from there.

Or is this conditional attachment of Controller/Datasource a core principle of MVC?

Perhaps there's an experienced dev around here to shed some light on this?

Does the function look up the handle of the Datasources or look in the datasource folder in workspace for the filename? I used a DS called <res:data-source name="page-content"/> as I'm used to seeing it like that in the debug.. but in fact I ended up having to use the name how it appears in the data-sources folder i.e page_content bug? intentional? This is a great idea by the way.

bug? intentional?

Intentional, kind of. It uses the handles used internally i.e. by the $context variable. Apparently the system translates those handles to a more XML-like dialect, with minuses instead of underscores.

Ahh gotcha! May be worth mentioning that fact in Readme? Took an hour to figure out I was using the wrong convention for the DS :)

Technically yes, somehow. Although I am not really convinced that mixing View- and Controller-logic would be a good idea. Or is this conditional attachment of Controller/Datasource a core principle of MVC?

Symphony isn't MVC, so the semantics don't matter too much. There are some similarities, but also a lot of differences. In MVC the controller decides which view to render, as well as what data to fetch via models and so on. In Symphony the role of the controllers and routing is split across pages, data sources and events.

A "page" in Symphony is both a routed controller (the page we edit via the Symphony interface) and a view (the XSLT file). Where this configuration lives doesn't really matter, hence defining your data sources inside the view file doesn't seem like too bad an idea. Wrapping these in conditionals may not be as technically clean as controllers in MVC, but the view is the only place Symphony allows developers to use conditional logic (via XSLT).

What we should not do is conditionally include data sources half way through view logic (e.g. using XSLT to check the XML result of one data source to conditionally include another) . That's messy, and thankfully I don't think it's even possible (as Henry suggests).

XSL Resource Loader updated to version 0.2 on 30th of June 2012

Regarding conditionals: What would make this very handy is the fact that I could include certain Data Sources only if a certain URL parameter is set or - and this is what Symphony currently doesn't offer out of the box – if a certain parameter is not set.

What would make this very handy is the fact that I could include certain Data Sources only if a certain URL parameter is set or - and this is what Symphony currently doesn't offer out of the box – if a certain parameter is not set.

I believe the Conditionalizer extension achieves this as well.

Lewis, You're right - it does :). And, thanks to latest changes in Symphony, it does not require custom field in a section anymore.

Conditionalizr is definitely one I will be using. I still use Nils' method of negation which is a little hacky.

Also, if I can do away with the Global Resource Loader in favour of this, then great.

While I absolutely love the idea of separating content and structure, I am a bit worried that the template itself might not be the best place for this kind of information. Instead, I would prefer to put the structure information in a separate XML file, for a few reasons:

• Storing the structure information in your template makes it very hard to build a gui for those resources. Think about custom datasources: as soon as they are edited by hand you want to block Symphony from accessing it.
• What if I have a very big, complicated template? By keeping the structure with the template, you will have to load the entire template, while all it needs is a very small piece of static information.

Please don't see this as critique, I love experiments like this, especially if they make us think about the problems we are facing!