regards,
goed

Configure::read(’debug’);

Also, I think the way they do the console has changed?

PS Beautiful blog template.

I have been playing around with implementing this functionality into the HeadHelper, and it’s been going quite well.

I’ve realised that compressing all of the JS into a single file isn’t necessarily more efficient. For the cases where I have a little custom JS on each page, it means that the larger libraries are duplicated into each page’s unique package. So I’ll rework this to support grouping, causing more than a single package to be created.

Also, the file naming is a little annoying. As you pointed out it is a good idea to have a unique filename for each modified version to avoid browser caching. However, when a new version is created it would be nice to destroy all the old ones (just to clean up), and keeping track of these is annoying. I appreciate the simplicity of the config file

Anyway, I’ll keep on plugging. It currently supports JsMin and Packer for JS, and CSS Tidy for the CSS. And no change to any view files, as I already use the HeadHelper for all includes.

One thing that is important to point out is that the timestamp portion of the filename is key because of another optimization trick – Expires Headers. With the unique filename, you can set the expires header for your javascript and CSS files to way out in the future, since any change to those files will result in a new filename and thus your user’s browser cache of your previous file won’t cause problems.

I understand your points with regards to automation, but I think that is a job left for your deployment process. I use Capistrano for deployment, so I just dropped in a line to my deploy recipe to run AssetPackager after the latest code has been put in place. Same thing for our packaging script for SlideShowPro Director. I think one thing many Cake bakers can learn from the Rails crowd is good, automated deployment.

That being said, the script ought to have a fallback of some sorts should the compressed version be absent. Maybe if no compressed version exists we just revert to including all the singles just like we do in development and print a warning via a comment in the HTML.

Anyway, all that said I’m still open to any code submissions you might have to make the cleaner/easier.

I also would like to see it a little more automated. I like the idea of in DEBUG = 0 it just has a file_exists() and skips all the timestamp stuff.

Great work.

Manual updating via console. I just know that people will forget this step after updating their JS, and pull their hair out wondering why the compressed version just doesn’t work properly. How about it automatically generates the compressed files if they don’t exist? Perhaps running as DEBUG > 0 destroys any existing compressed versions (in case they are out of date), and so the first request of DEBUG 0 will create them again? It would be one additional file_exists check every production request, but you’ve probably got higher overhead than that with the current timestamp method (I havne’t looked at your code yet).

The config file. I usually have a few CSS / JS includes in each layout which would be easily replaced as you displayed above. But I also usually have custom CSS / JS includes in each of my views – and I would like these to be included in the single page JS/CSS, without having to manage combinations in the config file.
What about if this helper worked like RosSoft’s HeadHelper ( http://rossoft.wordpress.com/2006/03/28/register-head-tags-from-helpers-2/ ), or the “echo $scripts_for_layout;” that Cake 1.2 provides? The AssetPackager can generate some identifier from all the script names that are passed to it, and automatically know what file to actually generate/include.

I’m busy on a non-Cake project at the moment so I can’t really implement these myself just yet. But if you don’t do it first I do plan to – I’m using a customised version of the HeadHelper at the moment and this would be a good addition.