documentcloud / jammit

I tried jammit with 3.0pre. Adding Jammit::Routes.draw(map) to the routes doesn't work.

Seems like a terrible idea to be using Rails.root and Rails.public path directly in your jammit.rb. Assigning to a constant no less so ruby will throw errors if you redefine it later.

There's a ton of other solutions. Lets move them into mattr_accessors or something...

Really doesn't make sense to use constants to define very dynamic data such as app paths. This is configurable stuff, not "set once and leave it".

I am trying to run "rake db:test:clone" in my Windows dev environment and am getting:

...
C:/Ruby19/bin/rake:19:in load
C:/Ruby19/bin/rake:19:in <main>
Missing these required gems:
  jammit
You're running:
  ruby 1.9.1.378 at C:/Ruby19/bin/ruby.exe
  rubygems 1.3.5 at C:/Users/Shaun/.gem/ruby/1.9.1, C:/Ruby19/lib/ruby/gems/1.9.1
Run `rake gems:install` to install the missing gems.

I the same error message (with a different stack trace of course) when i run "ruby script/server"

I've tried running "rake gems:install" of course and that appears to execute correctly.

I have also tried to manually run "gem install jammit" which looks like it works:

Successfully installed jammit-0.4.4
1 gem installed
Installing ri documentation for jammit-0.4.4... 
Updating class cache with 1187 classes...
Installing RDoc documentation for jammit-0.4.4...

When i run "gem list --local" is lists

jammit 0.4.4

so i assume that its installed. Im not sure Rails doesnt think its there.

Also, I am able to run "rake db:create" without issue.

The same project on an OS X system runs without issue. Any thoughts on why this issue is occurring and how to fix?

Thanks

Hi there -- I'm back for more trouble :).

Recently I realized that soon I'm going to need better JST functionality than 0.4.4 has (putting JST in with the JS, etc.), so I decided to take another stab at it. I know you want to wait for Rails 3 for 0.5.x, but I think this JST stuff is worthwhile enough to release as a 0.5.0 and then have 0.6.0 be Rails 3 (since the JST changes introduce deprecations, it shouldn't be 0.4.5).

In my dev branch (https://github.com/agibralter/jammit/commits/dev) I just pushed my latest commit:

https://github.com/agibralter/jammit/commit/2be5d1ae76eea6131d147aa2b75bec170c8b7b3a

The commit message say most of it, but basically, I rearranged test fixture names because they were becoming a little bit hard to maintain, I added a controller test finally :), and I made it so that people can specify template extensions with a config option (e.g. template_extension: "html.mustache"). I also made a pretty important change to how dynamically generated JS templates are handled (see the __templates__ stuff in the commit). I think this change makes Jammit's development behavior a lot more understandable.

I think there's one more piece of functionality that I want to add: proper scoping for JS templates with a template_base_dir config option. The way I see this working is that if a user specifies this config option, Jammit will build a nested object for all JST files located in this base directory.

For assets.yml:

template_base_dir: app/mustache_templates
template_extension: "html.mustache"
javascripts:
  default:
    - app/javascripts/*.js
    - app/mustache_templates/**/*.html.mustache

And a dir structure of:

• app/mustache_templates/home.html.mustache
• app/mustache_templates/users/index.html.mustache
• app/mustache_templates/users/show.html.mustache
• app/mustache_templates/posts/index.html.mustache
• app/mustache_templates/posts/show.html.mustache

You would get a jst part:

(function(){
window.JST = window.JST || {};
var template = function(str){var fn = new Function('obj', 'var p=[],print=function(){p.push.apply(p,arguments);};with(obj){p.push(\''+str.replace(/[\r\t\n]/g, " ").replace(/'(?=[^%]*%>)/g,"\t").split("'").join("\\'").split("\t").join("'").replace(/<%=(.+?)%>/g,"',$1,'").split("<%").join("');").split("%>").join("p.push('")+"');}return p.join('');"); return fn;};
window.JST['home'] = template(...);
window.JST['users'] = {};
window.JST['users']['index'] = template(...);
window.JST['users']['show'] = template(...);
window.JST['posts'] = {};
window.JST['posts']['index'] = template(...);
window.JST['posts']['show'] = template(...);
})();

The problem I see here is what happens if you also have a app/mustache_templates/users.html.mustache file? Perhaps it could be:

(function(){
...
window.JST['home'] = template(...);
window.JST['users/index'] = template(...);
window.JST['users/show'] = template(...);
window.JST['posts/index'] = template(...);
window.JST['posts/show'] = template(...);
})();

Embedding images with datauri doesn't work when you have a windows path with spaces.

Here's an example, with embed_assets set at 'datauri', run jammit. On one of my files (base-datauri.css), I find this inside

background:url(EMBEDC:/Documents and Settings/username/My Documents/Website/public/images/embed/bg_body_int.png)

When I move the code to C:\code, and run jammit, I get the embedded binary image.

It's possible this is a relatively easy fix...delimiting or putting path in quotes so long as that doesn't screw up other platforms. There's also no error message stating the embedded function did not work.

Workaround: Move code to non-spaced path.

I was just wondering... would it make sense to build some sort of system into Jammit to allow the browser caching of JS and CSS assets? What I imagine is something like this:

When the jammit command gets run, it calculates a MD5 checksum of each package and creates a file, assets.lock.yml in config/. That file could look something like:

package1: 50bda6102c8dd57a5ead84e99d493776
package2: 1dd5a5eabda693707672c8d84e99d450

It also symlinks (or copies) each package to have its MD5 checksum as a name:

50bda6102c8dd57a5ead84e99d493776.js@ -> package1.js
50bda6102c8dd57a5ead84e99d493776.js.gz@ -> package1.js.gz

Then, when the Rails app is running in production, include_javascripts(:package1) could instead generate:

<script src="/assets/50bda6102c8dd57a5ead84e99d493776.js" type="text/javascript"></script>

Also, a deployment script could copy these MD5-named assets to CDNs after running jammit.

Is this a crazy idea? Is there a way to do something similar already?

Unfortunately Content Negotiation using MultiViews requires the requested file to not exist on the filesystem. This was already pointed out in the comment by Ches Martin to this post: https://afreshcup.com/home/2010/1/18/notes-on-using-jammit-with-rails.html.

So in other words, in order for asset pre-caching to work under Apache the URLs generated by Jammit should omit the file extension.

This can be tested using the following .htaccess in the assets folder:

AddEncoding x-gzip .gz
Options +MultiViews
<FilesMatch "\.css.gz$">
  ForceType text/css
</FilesMatch>
<FilesMatch "\.js.gz$">
  ForceType text/javascript
</FilesMatch>

Here is an example request:

% curl -I -H 'Accept-Encoding:gzip,deflate' https://site.local/assets/style   
HTTP/1.1 200 OK
Date: Thu, 27 May 2010 09:56:03 GMT
Server: Apache/2.2.14 (Unix) mod_ssl/2.2.14 Phusion_Passenger/2.2.11
Content-Location: style.css.gz
Last-Modified: Thu, 27 May 2010 09:45:28 GMT
ETag: "75aef2-120f-4878c0f420a00;4878c75f4eec0"
Accept-Ranges: bytes
Content-Length: 4623
Cache-Control: max-age=31536000
Expires: Fri, 27 May 2011 09:56:03 GMT
Content-Type: text/css
Content-Encoding: gzip

I think a possible solution could be the addition of a configuration option to omit filename extensions in production.