cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kamal Bhatt <kbh...@tt.com.au>
Subject Re: Proposal - JS Reader
Date Mon, 14 Jul 2008 05:59:07 GMT
Reinhard Pötz wrote:
> Kamal Bhatt wrote:
>> 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 
>>> http://alchim.sourceforge.net/yuicompressor-maven-plugin/overview.html? 
>>> 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 
>>> http://repo1.maven.org/maven2/net/sf/alchim/yuicompressor-maven-plugin/0.7.1/yuicompressor-maven-plugin-0.7.1.pom

>>>
>> 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?
>
> A Maven plugin is just a JAR file that can be used as a normal 
> dependency. The yuicompressor-maven-plugin already contains 
> com.yahoo.platform.yui.compressor classes that can be used this way:
>
> <dependencies>
>   <dependency>
>     <groupId>net.sf.alchim</groupId>
>     <artifactId>yuicompressor-maven-plugin</artifactId>
>     <version>0.7.1</version>
>   </dependency>
> </dependencies>
>
> Provided that it's legally correct for an Apache project to depend on 
> this code (needs to be checked before somebody starts to code!!!), 
> this looks to be the simplest way to use a Javascript/CSS compressor.
>
OK, I think I get you. So we can use this plugin as a way of getting the 
YUI code without including it in Cocoon. Assuming there is interest in 
this project (of course).

-- 
Kamal Bhatt


Mime
View raw message