Symphony.

I see your points and agree, those are issues.

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.

That was actually one of the reasons I'd like to save such data in a file and not in the database: I really dislike having no choice but to use a GUI for all those tiny bits that are not PHP or XSLT.

Also, the resulting file is still valid XML, parsing and recreating the content without any data loss should be possible.

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.

I was thinking about that too. Right now the extension is loading and parsing the entire file using SimpleXML. It shouldn't be too hard to change that to XMLReader though; XMLReader is able to only partially read XML documents so that only the head of the file is considered. My guess is it will take really huge templates though to show a noticeable difference.

But let's first find out if "the power users" find it advantageous to do those bits in the XML rather than in the backend GUI.

XMLReader is C# isn't it? Do you mean DOMDocument? I think that both Simple XML and DOMDocument both load the entire file, so not sure if that will work as a benefit.

When it comes to super massive templates, if I start to go over 1000 lines of structured code in a template, I start to think about splitting that out into smaller templates, as utilities anyway. So from my perspective, super massive templates means I may be doing something wrong.

Also, this is all just text files, so parsing larger files shouldn't really be a performance hit.

Has anyone got any massive templates available that can be tested?

But let's first find out if "the power users" find it advantageous

I've already stated my position. Champing at the bit to use this on my next project.

Sorry, I think I went to the conclusion too fast, without explaining what I meant: I meant writing the bits of information in a separate XML file, not the template itself.

So, all the benefits of having the data stored in a file rather than the DB are still there, and so is the possibility to version control the structure. That way you can use the GUI together with manual editing, and you only have to load the actual information rather than that and the template.

Hope my post makes a bit more sense now:)

edit:

Also, this is all just text files, so parsing larger files shouldn't really be a performance hit.

What about memory usage? From experience parsing XML can be quite heavy.

Yes, I understood it that way. Still, at the moment I think having a single file is a much more clean solution that spreading stuff across multiple files.

Also, the GUI could still parse the entire template, just modify the attached resources bit and leave the remaining file untouched. I don't think it's impossible per se.

It basically boils down to "making compromises in the system-implementation to make the GUI work" vs "having to jump through hoops in the GUI-implementation to make it work with a clean system". I am currently siding with the latter one.

Also to my understanding PHP's XMLReader is a SAX-based interpreter meaning it parses bits and pieces of the file instead of reading in the entire DOM.

Still, at the moment I think having a single file is a much more clean solution that spreading stuff across multiple files.

Funny, I very much prefer it the other way around. To me putting data into the template feels dirty and hack-ish. Especially if you have to go through hoops by using different XML parsers to get the performance right.

Ah well, I guess the only thing I can really do is write the other implementation if I am to whine about it ;-)

I don't have much to add (and a little late on the game), but really wanted to join in on the conversation!

As Nils said, SAX-based interpreter reads data in streams rather than the entire file. In any case, the load at the level that we're dealing with is very small. If load does become an issue, then your problem would be the way you're coding your templates.

Regarding segregating component loading into its own xml definition file, those interested might want to take a look at the now defunct S3 build. It does exactly this.

On the topic of separate definition file v.s. declaring resources inside the template: while keeping resource definitions separate is the cleaner approach, it's more alluring an idea to be able to define resources in situ to the template file. This methodology is like the reverse of browser (client-side) XSLT transformations, whereby the XML data is provided with an include declaration to the template file.

It's nice to be able to look at an XSLT template and know exactly what resources are being loaded.

It's nice to be able to look at an XSLT template and know exactly what resources are being loaded.

Just why I like it.

In Symphony 2.4 pages are stored as XML and not in the database, so the performance should be much the same. In 2.3, keep in mind that the query is going to run regardless of if this extension is installed or not.

I think this extension offers developers a choice between defining resources through a GUI or in a file. So each to their own really, cool experiment though! I'm interested to see how it evolves.

I somehow love the idea of this extension.

So then. Does this extension make it easier to attach global resources to a page?

Say I have a master xsl file. If I attach my global resources to this xsl file, and then import it, does it import the resources to the page?

If so, this could be a godsend for my latest project. I would rather move away from the Global Resource Loader.

Not yet, no. The changes required for it should be pretty marginal though.

But I fear that the performance could degrade in an uncontrolled fashion (i.e. a full recursion) or that the the list of attached components could become uncontrollable (like having too many components, you start losing track of what's coming from where)...

But I fear that the performance could degrade

Yeah, I can understand that.

It would be interesting to try it, and see if the resource references could be cached in some way so that if the file was modified it reloaded the references.