cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kamal Bhatt <>
Subject Re: Proposal - JS Reader
Date Sun, 13 Jul 2008 21:52:32 GMT
Reinhard Pötz wrote:
> Kamal wrote:
>> Hi,
>> It occured to me that Cocoon could probably benefit from a Javascript 
>> Reader. This JS Reader would do what a normal resource reader would, 
>> unless the user specifies a compression-method parameter. If the 
>> compression method is supported, then the JS will be compressed. 
>> Right now, I think we can only use JSMin[1] or Package[4], as Dojo 
>> ShrinkSafe[2] and YUI compressor [3] rely on custom version of Rhino. 
>> Packer [4] is written in plain old javascript. JSMin and Packer are 
>> open source, but it is not distributed on any Maven repositories that 
>> I can see, so we would need to include them in source.
> Have you had a look at 
> This plugin could be used as part of the build process. Then you could 
> use the uncompressed Javascript files for development and then when 
> the module is packaged, the Javascript and CSS files could be compressed.
> And, AFAICS, this plugin uses standard Rhino (1.6R7). See 

Hmmm... Don't know how they did that. I will look into it.
>> This would be useful for the (very large) JS dependencies in CForms 
>> (though, it could be argued that we should be bundling the already 
>> compressed version of Dojo and the other Cocoon JS files).
>> I, personally, would find something like this really useful as we 
>> have lots of code that we like to keep uncompressed for development, 
>> but compress at runtime.
>> What does everyone think? I don't mind coding this up (using just 
>> JSMin).
> I'm not sure if it is really good idea to compress Javascript files at 
> runtime.

I guess that depends (in part) on whether people generate javascript at 
run time. If so, then it would be useful to create this reader.

> If you write the plugin, it would also be possible to reuse the 
> yuicompressor-maven-plugin but not as Maven plugin but as a normal 
> dependency. By doing it this way you wouldn't have to pull in any 
> third-party code into our code base.

I don't follow this, can you elaborate?

Kamal Bhatt

View raw message