Symphony.

@iwyg found a bug in my Asset Compiler extension where it doesn't resolve XPath variables, e.g. {$workspace} in the hrefs. Can anyone point me in the direction of how I could go about accessing page parameters like $workspace from PHP in my extension.driver.php file? Is there an API call to get the page parameters? I had a look through the API docs but quite frankly I'm not even sure what I'm looking for exactly.

Many thanks for reading.

I think the whole concept is wrong. Consider different pages may have different stylesheets and different script files. Would that work with your extension?

I've hacked a little something here that is capable of all this. You may give it a try

I'm not for a moment suggesting it's the definitive answer to the issue at all, but it works absolutely perfectly for all the sites I manage (which admittedly aren't huge 'enterprise-y' applications). I can very simply list all the styles and scripts in standard HTML link and script tags during development (which are simple, easy & central to edit/remove - no separate manifest file needed, XML config, gruntfile.js etc), one-click in preferences compiles and minifies all my sites' assets, updates all the connected multi-manifest-setup config.php files and adds a unique MD5 hash to cache-bust (never again have to tell clients to hard-refresh their browsers to get the latest changes). Then it's a simple git push and my updates are deployed to staging then production. To describe that as 'the whole concept is wrong' is, I feel, more than a little unfair.

As for the different styles and scripts for different pages - sure there are times when you have such large and varied stylesheets and scripts that you need to modularise it, but those are very specific instances, most of the time the benefits you get from minimising everything into a single production-1a2b3c4d.min.css/js file far outweigh the slight extra size in asset file. 1 HTTP request for CSS and 1 for JS (both Gzip'd by the server) - given the ever increasing speed of bandwidth if these two requests are your apps' bottleneck then quite frankly you must be the God of Database Optimization & App Tuning.

Sorry, I was a bit unclear here. I just think you're trying to hit the problem from the wrong direction if you want to resolve FE parameters from the backend as you'd have to recreate some application logic. There's an entry point to grab resolved script/css elements and that'd be the FrontendOutputPostGenerate delegate. Your concept only works if the website meets the all assumptions that your extension is making about it: master template is master.xsl, all styles and scripts are hardcoded in the master template file, and styles and scripts don't change across all pages. So if you really want to go this way, it'd be easier to scrape a page from the backend (maybe curl) and get the results back from there. Speaking of scraping, you may also want to use Xpath instead of scraping the output string using regular expressions, but that's just my two cents.

I tend to (and I guess may others do) store assets in a separate template, giving me a slightly better control over what to include based on certain parameters, e.g. development vs. production, desktop vs. mobile, and so on. Your concept wouldn't be capable of this. Then, if one of the files has changed, you'll have to re-compile them manually, which is error prone. I know you're compiling assets from the backend to hit your website as little as possible, which is good, but leads to these limitations.

What I've done in my little hack is a complete different approach. The extension is listening to the FrontendOutputPostGenerate delegate, and checks weather scripts need recompilation or not. This is for sure not the definite solution and it adds slightly more overhead to the website than yours, but hey, that's the price for automation (aka laziness), isn't it :).

Yes you're right, my extension does target a quite specific use-case, I guess I feel as though that use-case might be considered the bog-standard, beginner-friendly, generic HTML approach to assets. You have a master layout and reference all your site's assets from there. You're absolutely correct though that there are a huge number of other use-cases not well served by my approach at all - and I think your extension seems to address those in a much more robust fashion. My approach was inspired by the build script process used by HTML5Boilerplate and grew out of that. Perhaps I should add to my documentation that this approach is probably best suited to brochure-type sites rather than more complex application type sites - I suppose I just assumed that anyone working on those type sites would know which is the best approach for them to take, and see/know the limitations in my extensions' approach - but yeah, perhaps I should make that more explicit in my docs.

I've also used in my time Rails' Asset Pipeline, Laravel's Basset package, Ant build scripts and Grunt.js - all frankly have their own strengths and weaknesses. As you say I don't think there is a definitive solution to this problem, otherwise someone somewhere would have found it by now :)

Btw, do you have any links to info about storing assets in separate templates? I haven't come across this before and it sounds interesting

I had another look through the API and found the FrontendOutputPreGenerate delegate (I use PostGenerate too currently) and that passes in the XML & XSLT context, I'm thinking whether rewriting my extension to use that delegate might be a good way of providing support for the XPath variables and dropping the reliance on master.xsl being hardwired. (I know, this doesn't address the wider strategic concerns you have with my approach, but would at least allow those two improvements/fixes)

Re: XPath vs Regexp - Thanks for the idea, interestingly enough I did originally use XPath but it ended up being way more code for something that could be achieved with just a couple of calls to preg_replace() but yeah, I know what you mean, XPath is definitely a cleaner and more robust approach than regular expressions :)

@iwyg - Had a closer look at that FrontendOutputPreGenerate delegate and realised that that wouldn't work, like you said it would involve recreating a lot of application logic. So scratch that idea :)

I think I'll update the docs to my extension detailing where it will best work and where it won't, limitations etc - I still think it's a useful approach for some people's workflow, not least my own - but to answer the original question: resolving XPath variables in the context of this problem is a non-starter.

Thanks for your input @iwyg, and the interesting discussion. Good luck with your extension, always good to have more & varied asset compilation options for Symphony! :)