How: Building your own combined css/js or extra groups for compression logic

I've been thinking about an API for this and perhaps the best way to do it is to be a lot more explicit. Currently the API is that the theme and modules can call $theme->script() and $theme->css() in the head and admin_head events with their additions, and then in $theme->head() we combine the scripts and dump them out. I agree this doesn't give the themer much control. How about if we have an API like this:

$theme->start_combining("script,css")
This goes in the theme and lets the code know that we're going to combine scripts and css for performance. Without this call, any calls to $theme->script() or $theme->css() just get dumped out immediately. So you can just comment out this call when you want to debug the theme.

$theme->print_combined("script")
This goes in the theme and prints out any javacript that we've combined so far and stops further combining until there's a future $theme->start_combining("script") call.

The $theme->head() call will stop doing any combining. This will be backwards compatible for existing themes in that they'll still work, except they'll stop having combined scripts/css. But I can do this in 3.0.1 without a major ruckus. How does that sound Serge?
---
Problems? Check gallery3/var/logs
file a bug/feature ticket | upgrade to the latest code! | hacking G3? join us on IRC!

Compressors in PHP are pretty slow, I fear that they're costly to use at page load time. I guess the result gets cached so maybe its worth it. Thoughts?

Yes, right -- printing is a bad idea but getting the result back works. I'd like to keep it simple for most though so how about if the "core" group is the default? Then it'd be (copy/paste from above, amended with your suggestions):

$theme->start_combining("script,css")
This goes in the theme and lets the code know that we're going to combine scripts and css for performance. Without this call, any calls to $theme->script() or $theme->css() just get dumped out immediately. So you can just comment out this call when you want to debug the theme.

$theme->script($path, $group="core")
$theme->css($path, $group="core")
If we're combining, then provide a script or css link. If we're not combining then just return a well formed script/style element. Modules would typically leave the group off and be in the core group, but the theme can create different groups. So this would be a backwards compatible API change (important for 3.0.1 which isn't supposed to break module APIs)

$theme->get_combined("script", $group="core")
Return a script/style element referring to the combined result. This goes in the theme and prints out any javacript that we've combined so far and stops further combining until there's a future $theme->start_combining("script") call.

If that works for you, I can get it into 3.0.1
---
Problems? Check gallery3/var/logs
file a bug/feature ticket | upgrade to the latest code! | hacking G3? join us on IRC!

From a new module/theme developer point of view I feer that we are adding complexity where we don't need it.
I think the only major issue here is that the module/theme developer should be able to urn on or off combining.
Then add more complexities ( minify/compression ) later.

Dave
_____________________________________________
Blog & G2 || floridave - Gallery Team

@Serge: I wonder if Minify is better than JSMin (http://www.crockford.com/javascript/jsmin.html) which we currently use for minifying some of the vendor JS that we stick in the lib dir. I'll have to try them out. There's also CSSMin: http://code.google.com/p/cssmin/

The implementation of this API is in the core code, but it'd be used by the theme.
https://sourceforge.net/apps/trac/gallery/ticket/1600
---
Problems? Check gallery3/var/logs
file a bug/feature ticket | upgrade to the latest code! | hacking G3? join us on IRC!

Ok, I did a first pass at minifying JS and CSS. It's really slow.

My normal server side render time is 700ms.

JSMin costs: 12.1 seconds
Raw size reduction: 266k->237k (11%)
Gzipped size redurection: 74k->65k (12%)

CSSMin costs: 1.6 seconds
Raw size reduction: 71k->53k (25%)
Gzipped size reduction: 14.7k->10k (31%)

This makes sense because most of our Javascript is already minified whereas most of the CSS isn't. After the minified version is cached, it's back to 700ms of course, but the first load is really really long :-/. I'm not convinced the gain is worth the cost. But we can extend the get_combined() API to provide a minified argument, eg:

$theme->get_combined("script", $group="core", $minified=false)
and then the themer can decide. Do you want to do that? Theoretically in that case you could create a group for JS that hasn't been minified yet and just minify those... Do you think you'd use that?
---
Problems? Check gallery3/var/logs
file a bug/feature ticket | upgrade to the latest code! | hacking G3? join us on IRC!

well, I am still not convinced much that all this combining is worth the trouble in the first place.
Mind though that combining today is kind of slow anyway as it does combine too often
what is a decision point for to use cache or not?
In general I would think that caching of anything should be done by 3rd party module with its own settings and all (see WP-Supercache for wordpress)
otherwise, since we are doing it then if cache is rebuild properly, then compressing it on the fisrt run is not a problem (mPoV)

fair enough, but

you are missing the point. it is not about debugging, but about managebility and choices.
why do you empose on me, as a developer of the theme/module, when, how and in what form css/js references are placed

I am all for combining, but leave it for me to decide how many files combine into, when to inject them or I may want to defer it.
with proposed changes it would be easily achievable

I am sorry I missed your point. If we add many choices it becomes complex to support and document.
I just don't want to see more complexity for the new theme/module developer to learn.

Lets hope it does not get too complex and slow with docs that need to be written to explain it all.

Dave

_____________________________________________
Blog & G2 || floridave - Gallery Team

Comments are now permitted for this topic.