Re: Proposal - JS Reader

[gregers <na...@spamgourmet.com>]

This might be a little too late, but there is a similar project. It's not a
Cocoon plugin, but a servlet, which is somewhat close to a Reader, from what
I understand...?

The project is called JAWR
https://jawr.dev.java.net/

It's a servlet that compresses all your javascript and css on server
startup. It can bundle serveral javascript to one package, as well as
compress every single js file. Supports minification with YUI Compressor and
some others, as well as gzipping requests.

I've tested it for a project I'm working on, but think I'll go for the YUI
Compressor Maven plugin instead. Mostly because we create a javascript api
that is needed by external partner sites, and JAWR doesn't have a good
solutions for serving javascript to external sites. It's possible with a js
include, but not an optimal solution imho.

Regards,
Gregers
-- 
View this message in context: http://www.nabble.com/Proposal---JS-Reader-tp18415990p18959110.html
Sent from the Cocoon - Dev mailing list archive at Nabble.com.

Re: Proposal - JS Reader

[Jeremy Quinn <je...@apache.org>]

Hi Guys

IMHO the most likely scenario ATM will be that JS libs for eg. CForms  
would be minified and packaged as a production step, either manually  
or automatically. Then served as Mark says, via HTTPD using gzip  
compression.

i.e. there is more than just compression involved

But, I have not got this far yet .....

regards Jeremy

On 13 Aug 2008, at 17:42, Mark Lundquist wrote:

>
> I guess a JS reader could be helpful for applications where all  
> resources are served directly by "raw" Cocoon, i.e. if any  
> compression is to be done then Cocoon has to do it.  But don't most  
> applications in a Web setting run Cocoon behind an Apache front- 
> end?  Then you can just have Apache gzip whatever you want, all  
> outside of Cocoon, right?  And wouldn't that take care of whatever  
> one might want to gain from using a special compressing/"minifying"  
> component for a specific resource type?
>
> I could be totally wrong about this, but that's just how it seemed  
> to me... anyway, is the use case for this specifically the scenario  
> where un-Apache-front-ended Cocoon is being used to serve resources  
> directly?
>
> cheers,
> —ml—
>

Re: Proposal - JS Reader

[Mark Lundquist <lu...@gmail.com>]

I guess a JS reader could be helpful for applications where all  
resources are served directly by "raw" Cocoon, i.e. if any compression  
is to be done then Cocoon has to do it.  But don't most applications  
in a Web setting run Cocoon behind an Apache front-end?  Then you can  
just have Apache gzip whatever you want, all outside of Cocoon,  
right?  And wouldn't that take care of whatever one might want to gain  
from using a special compressing/"minifying" component for a specific  
resource type?

I could be totally wrong about this, but that's just how it seemed to  
me... anyway, is the use case for this specifically the scenario where  
un-Apache-front-ended Cocoon is being used to serve resources directly?

cheers,
—ml—