Different Asset Cache destination based on scripts included

[zeroasterisk]

I have a bunch of layous JS files, and on a few elements I include an additional JS file...

I could of course, designate one group or another (or both) with a destination but then i'll end up having 2, or 3, or 4 different JS files to download (depending on how many unique destinations I put on a page).

I implemented a somewhat dirty hack which might be a good idea for a feature in the future... basically I have an array of all my scripts to include and create a new destination based on that array... so it's always unique to those scripts, but if those scripts change, the cache file changes...

if (!empty($this->Output->scriptsToInclude)) {
    $destination = 'js-'.md5(serialize($this->Output->scriptsToInclude));
    foreach ( $this->Output->scriptsToInclude as $script ) { 
        echo $this->AssetCompress->script($script, $destination);
     }
}
echo $this->AssetCompress->includeAssets();

Obviously, since AssetCompress helper builds it's own internal array, it would be very easy to implement something like this in the helper, based on a setting.... and I wouldn't have to collect my own array just to pass it into yours.

You may argue that the user would be better off with 2 files to download since they already have one of them in their cache (supposedly) and but those arguments all vary a lot by design and circumstance...

I found this useful and perhaps others will as well.

[markstory]

I've thought about instead of 'default' as the default build file, it uses the slugged version of all the included file basenames appended together. This would do much of what you wanted, and fix issues where people use the plugin without planning build files, and getting confusing results.

[zeroasterisk]

sure, either way... though i've got a bunch of awkward file names, haven;t played with the sproketsy JS requirements yet

[markstory]

Slugging the files should just result in a long filename, which isn't that much different than an MD5.

[markstory]

I've added a new slug-branch for this feature, so far I've added the filename slugging in 85aac62. I could see the filenames getting a bit silly long though. Perhaps hashing the files would be better?

[zeroasterisk]

Hashing is what I chose because the slugged filenames (which was my first instinct) were pretty long and I decided that I really wasn't going to be looking at the filenames much anyway...

[markstory]

I agree that the hashes would be better, and I've implemented them in 25c8525.

Thanks for the ideas :)