Re: Proposal - JS Reader

2008-08-14 Thread Jeremy Quinn

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

2008-08-13 Thread gregers

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

2008-08-13 Thread Mark Lundquist


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

2008-07-14 Thread Kamal Bhatt

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
groupIdnet.sf.alchim/groupId
artifactIdyuicompressor-maven-plugin/artifactId
version0.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



Re: Proposal - JS Reader

2008-07-14 Thread Jeremy Quinn

Hi Kamal

One of the items on my (long) list of jobs to get done, in my re- 
working of CForms/Dojo is compression/minifying/packaging etc.


There are a number of different scenarios that I can imagine people  
will want to for it, but TBH, I have not thought it all through yet 


1) development : uncompressed/un-minified, each 'class' loads separately
2) production (a) : single compressed/minified js file containing just  
the dojo and cforms code to support one cform, application or site.
3) production (b) : single compressed/minified js file containing just  
the cforms code to support one cform, application or site, with dojo  
loaded from CDN.
4) production (c) : load everything from CDN (i.e. arrange to put  
versionned CForms JS in eg. http://code.google.com/apis/ajaxlibs/) no  
idea if they'd be up for it .


As I said, I have not looked into this very closely yet, but I assumed  
the first level of support would be documentation on how to use Dojo's  
built-in compressor within Cocoon manually, with support in the XSLT  
to allow a developer to specify a specific js file to load instead of  
all of individual dojo/cforms.


I think you need a config file to drive dojo's compressor. It would be  
interesting to see if this could be automated by a maven or ant build  
task.


regards Jeremy

On 12 Jul 2008, at 05:24, 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.


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).


Apologies if something like this already exists.

Cheers.

[1] http://www.crockford.com/javascript/jsmin.html
[2] http://dojotoolkit.org/docs/shrinksafe
[3] http://developer.yahoo.com/yui/compressor/
[4] http://dean.edwards.name/packer/src/




Re: Proposal - JS Reader

2008-07-13 Thread Reinhard Pötz

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


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.


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.



Apologies if something like this already exists.


Not that I know of. You are welcome!

--
Reinhard Pötz   Managing Director, {Indoqa} GmbH
 http://www.indoqa.com/en/people/reinhard.poetz/

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member  [EMAIL PROTECTED]



Re: Proposal - JS Reader

2008-07-13 Thread Kamal Bhatt

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



Re: Proposal - JS Reader

2008-07-13 Thread Reinhard Pötz

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
groupIdnet.sf.alchim/groupId
artifactIdyuicompressor-maven-plugin/artifactId
version0.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.


--
Reinhard Pötz   Managing Director, {Indoqa} GmbH
 http://www.indoqa.com/en/people/reinhard.poetz/

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member  [EMAIL PROTECTED]