Fix JavaScript caching and put together sys admin recommendations

[jerboaa]

Have a look at this:
http://apidock.com/rails/ActionView/Helpers/AssetTagHelper/javascript_include_tag

plus comments.IIRC we are using :cache => true which makes it cache to a file called all.js. We could advise sys admins to create that file and make it writable by mongrels. This might convince them to turn JS caching on.

More on this in old #176.

[benjaminvialle]

Yes, I am having this issue too with Passenger. We may do something wrong in the way we cache things… I don't know what is happening here O_o

[benjaminvialle]

Some screenshots of what is happening in production mode with Passenger (and I guess it is the same thing in Mongrel):

http://bvialle.eu/pub/file.php?h=Raf2b96f086f06b363ed099b43f6ef5f0

http://bvialle.eu/pub/file.php?h=Ra710cd8569ae1c4dbc00c2f18d34b51f

[jerboaa]

I can't view your screenshots, unfortunately. It gives me the php file, which - when downloaded - I can't open. I think the cleanest solution to this is to create a directory in public/javascripts, say "cache" and let Rails write there if the system admin is comfortable with that.

In a proxied setup this breaks things too. At least the way we recommend the setup to be. We need to put more thought into this JS caching issue :)

[benjaminvialle]

Btw, it is a bug in my file uploader system. But try to open it with an image editor, like eog for example. It works :)

[jerboaa]

Nice bug ;-) I guess you're not setting the mime-type properly. And yes, that looks very much like something I've seen before. I confirm, it's applicable to a mongrel setup too.

[jerboaa]

Benjamin, I had a brief look at this and it appears that all the Rails :cache thing is doing for javascript/stylesheet tags is concatenate them together into one file. It does not strip comments or the like. I'm not really seeing what the big advantage of this is. At the moment the best way I can think of handling the read-only situation is to run MarkUs with js caching turned on, let rails produce those files and then ship them (the cached files) in our release. Overall it seems to be a bit backwards, though. Does anybody have a better idea?

BTW: I was able to reproduce the scroll-bar issue in the grader view. Key is to turn JS caching on. Not sure why. I fixed a few styles and it looks ok now. I'll post a review soon.

[benjaminvialle]

Ok. Severin, what we could do is, for the moment, deactivate javascript caching by defaut (I think it is enabled for production by default) and move this issue once we will have move to Rails3. There must be better mechanisms with Rails3 and it may simplifies things.

I know we can keep all ":cache => " lines in the code if we only deactivate javascript in config/environments/*.rb environments.

What do you think ?

[jerboaa]

That would be an option. I would rather get rid of our :cache directives.

$ grep -rn ':cache' app | wc -l
13

There aren't too many anyways. Then we should revisit caching in a more serious approach. I'm reluctant to ship with config.action_controller.perform_caching = false by default, since this turns off other caching as well. Caching best practices is worth an entire wiki page on its own (at the very least) and we shouldn't take this lightly. For a 1.0 we could come with config examples for memcached, ship with minified/restructured javascript files (they are scattered all over the place in public/javascripts), etc. There is lots we can do. Do you think that would be OK?

[benjaminvialle]

Ok. So go for it. :) We only remove javascript caching for the 0.10.0 release.

[jerboaa]

Ok. I'll keep this issue open and set the milestone to 1.0, though.

[reidka]

Is it time to review js caching?

[benjaminvialle]

Maybe better after JS cleanup (see #1496)

[david-yz-liu]

I'm not really sure that this issue is still relevant; @reidka I'm going to close it for now.

But perhaps I don't understand the problem; a clearer description might be helpful too.