Adding Compression and File Concatenation to HtmlHelperProperty

[brianfitzgerald]

I've been bothered for a while now by my multiple JS files that need to be served by the server on every request. It seems like a really nice addition to the HtmlHelperProperty? would be to use the configurations we have set up in the xml config and concat and compress the files into one before inserting it into the Head of the document.

 http://groups.google.com/group/mach-ii-for-coldfusion/browse_thread/thread/6a89a340ce94b3ac?hl=en

The question is how to do this w/o muddying up the mach-ii install w/ JARS and what not. In this thread, Mark Mandel suggested his JavaLoader?, but I don't have any experience w/ it so I can't really comment on whether or not it could be a good solution.

Anyway, it might be a headache, but if it could work, I think it would make an awesome enhancement

[peterfarrell]

I sorta didn't answer on the list but we open up a large door if we start shipping JARs and a loader etc. The real question is do what really want to "support" that out of the box? My answer is that people will either be:

1. Be upset on our choice of JS compressor (either Packer, JSMin or Yahoo Compressor)
2. Be upset that whatever compressor we use, it will be out of date and require patching for new features by the end user anyways.
3. or lastly, just plain don't care if the HTML property does JS compressing.

Also, people we be upset if the compressor breaks their code. So I'm thinking we should fall back to our extensible architecture theme and just let people plugin what they want through some API. We could ship with a JSMin and Yahoo Compressor adapter -- but you'd have to load in the JARs using Mark's loader or drop the JARs in the CFML class path yourself. Just thinking it could be a support nightmare if we start bundling a whole ton of stuff.

Concatenation of files is another issue entirely -- however it can solved in CFML using the Java IO package and reading in files into a stream. The harder problem will be managing the concatenated files in a cache and then have certain people moan that their shared hosting doesn't let their CFML server write to disk and they cannot use this feature.

For the sake of getting 1.8 out the door in May (hopefully), I'm just preliminarily targeting this for 1.9 unless Brian you want to take point on this. Maybe do some research on the compressors and maybe spec out a "common" API (adapter CFC) that people can extend (or we can extend) to talk to these third-party compressors.

[peterfarrell]

Added to the 1.9 milestone

[peterfarrell]

Re-targeted for the Integrity Milestone 1

[peterfarrell]

Retargeted to more sensible milestone

[brianpickens]

If I may chime in on this, we've had alot of luck with googles closure compiler.  http://code.google.com/closure/compiler/ The only thing is that we highly recommended any javascript code is validated with JSLint first. Not doing so could produce errors in the resulting script... You can choose to use their JAR (which we do), or you can use googles API service. The API service could be useful to avoid bundling JAR files.

[peterfarrell]

Brian, thanks for chiming in and making a good suggestion. The one thing I have been thinking about this is where do we draw the line between doing this at runtime (like on application start) and when something like this should be part of the build process? For example, in our applications -- we always use ANT to build a "package" that we can deploy to production. During this process we use JSMin (or any other service like Google Closure API calls) to "compress" our JS. This is better suited to build process whereas in other circumstances I can see it done not during the build process.

[brianpickens]

Hmm, but isn't the build process outside the scope of the Mach-II application? Also, just how common are automated build process used? I know at our organization we simply update our cluster with an svn update. And I know that in discussion with our systems guys, they didn't want to complicate this process and wanted us to find a way of doing it either manually our selves within our coding process (which is what we do), or programmatically within our code base. Now, I realize I may be way off base with the way ant works, but then I really don't know anything about ant.

[peterfarrell]

Yes, that is my point exactly that some things are best left to the build process. Actually, automated build processes are extremely common -- especially languages that need to be compiled. With Java, you would always see a build process either ANT or Maven. Even Mach-II itself has a build.xml file which we use to test, build, zip and ftp nightlies or stable releases.

In my opinion, JS compression can be programmatically or in the build process. In our applications at work, we do it during our ANT based build process -- compression via JSMin and validation via JSLint. We also use the CFML var scoper tool to check for un-var'ed variables, MXUnit / CFCUnit for unit tests and Selenium for functional testing (UI tests). Basically, everything has to pass in order to "certify" the build for staging or production.

Personally, CFML application development could greatly benefit from more "strict" build processes versus the typical SVN update or even basic FTPing of files.

[peterfarrell]

Just retargetting to untargeted for the moment so we can get a better handle on when this might be implemented. M2 of 1.9 isn't the right place yet.

[matt_woodward]

 https://github.com/Mach-II/Mach-II-Framework/issues/51