Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <487A7920.8090701@tt.com.au>
Date: Mon, 14 Jul 2008 07:52:32 +1000
From: Kamal Bhatt <kbhatt@tt.com.au>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: Proposal - JS Reader
References: <487831E8.7060805@tt.com.au> <487A0AED.8040903@apache.org>
In-Reply-To: <487A0AED.8040903@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

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?


-- 
Kamal Bhatt