In the “old days”, you’d override to_json in your model class to provide a JSON implementation of your model. Then in your controller, render :json => @model would work perfectly. And some folks would even redundantly code render :json => @model.to_json, and that would work too.

to_json even had some great options for ActiveRecord objects! You could tell the method to only render certain attributes, or to include associations or method calls!

render :json => 
  @user.to_json(:only => [:email], :include => [:addresses])

Life was good. But things start to fall apart when you want to do something a little out of the ordinary. Like return JSON with the model as part of a bigger structure.

render :json => { :success => true, 
  :user => @user.to_json(:only => [:email]) }

Oops. {\"user\":{\"email\":\"me@example.com\","success":true}has the JSON characters escaped, which is not what we want. So what do we do? We hack around it:

render :json => { :success => true, 
  :user => { :email => @user.email } }

But this doesn’t scale – we have to explicitly create the JSON by hand in the controller. What if we need 5 or more attributes? Yuck!

Enter ActiveSupport 2.3.3. Now the creation of the json is separate from the rendering of the json. as_json is used to create the structure of the JSON as a Hash, and the rendering of that hash into a JSON string is left up to ActiveSupport::json.encode. You should never use to_json to create a representation, only to consume the representation.

def as_json(options={})
  { :email => self.email }
end

Anytime to_json is called on an object, as_json is invoked to create the data structure, and then that hash is encoded as a JSON string using ActiveSupport::json.encode. This happens for all types: Object, Numeric, Date, String, etc (see active_support/json).

ActiveRecord objects behave the same way. There is a default as_json implementation that creates a Hash that includes all the model’s attributes. You should override as_json in your Model to create the JSON structure you want. as_json, just like the old to_json, takes an option hash where you can specify attributes and methods to include declaratively.

def as_json(options={})
  super(:only => [:email, :avatar], :include =>[:addresses])
end

Your controller code to display one model should always look like this:

render :json => @user

And if you have to do anything out of the ordinary, call as_json passing your options.

render :json => { :success => true, 
  :user => @user.as_json(:only => [:email]) }

The moral of the story is: In controllers, do not call to_json directly, allow render to do that for you. If you need to tweak the JSON output, override as_json in your model, or call as_json directly.

Fix your code now to use as_json – it will be one less thing to worry about when you migrate to Rails 3.

This post was inspired by the investigation I went into while exploring the answer to this question on Stack Overflow.

Hey Brian Morearty – Rails was never Javaficated to begin with. So the answer is yes.

We decided that delayed_job is an easy and solid way to get background tasks running in your Rails app, but if you are a massive site that needs a heavy-duty and configurable solution, then Resque may be what you need. Resque’s complexity makes this a non-trivial decision! Start with delayed_job since it’s so quick to implement, and you can always choose another solution later.

Want to get delayed_job running in your app in 10 minutes? Follow the steps in Delayed Gratification with Rails.

Just drop that into an file in config/initializers, restart, and get styling!

To run jslint as a rake task in your Rails project, you’ll only need a few things:

• the Java runtime
• Rhino, the java-based javascript runtime environment
• jslint itself
• a rake task to invoke it

So let’s get it set up. First, the java. Drop into a shell on your development system (or build system, wherever you want to run jslint), and make sure you have access to the java runtimes (run java -v, or which java). If not, go get it. Don’t be afraid, it’s easy.

Next you’ll need Rhino, the javascript execution environment. There are many js implementations (spidermonkey/treemonkey, v8, etc), but Rhino is the one that Crockford chose when he wrote the extension to jsunit that loads a file to be parsed. Its a jar file, go get it and put it into your project as vendor/rhino.jar.

Now you need Crockford’s jslint code. There are two parts: one is jslint.js, and the other is the Rhino extension (rhino.js). We will need both of these, and I’ve found it’s easiest when they are combined into one. Concatenate rhino.js to the bottom of jslint.js and save as vendor/jslint.js.

Hey, we’re almost there! Now you just have to add the rake task to your project.

Drop this gist into an existing Rakefile, or rake task. If you don’t have any rake tasks, then simply save this as lib/tasks/jslint.rake. Rake will find it in your project automatically. Run rake -T to confirm.

A short explanation: it finds all the js files you want to inspect, and runs jslint on them one at a time, printing out failures. Line 6 is the key line – you can change two parts of this to suit your project. First, the list of files to check is created using a Dir glob. My example gets all .js files under /public recursively (*). Then the second part of that line is used to reject js files you DO NOT want to inspect. Frameworks, 3rd party code, for example (although it can be fun to run jslint on your framework code to see their level of quality). This example excludes the ExtJS installation.

Now youre ready to run

rake jslint

and enjoy the benefits of quality-checking your JavaScript code! And since you’ve just built a rake task that returns 0 or 1, it can be easily integrated into you automated or continuous build process. Heh heh – now the build will fail and everyone will know who doesn’t use triple-effing-equals! (see slide 13 of Naked JavaScript)

Enjoy command-line jslint. And if you develop using TextMate, I highly recommend integrating jslint into that as well.

(I’ve been thinking and talking about this for too long. Inspiration to finally get command-line jslint set up came from reading this stackoverflow earlier today.)

This means the url in the browser location bar will NOT end with “.csv”. Don’t do this on Rails 2.2.2 and earlier!

Rails 2.2.2 properly sets the Content-Type to text/csv. But that’s not enough for our browser to know what to do with it. Poking around this morning reveals that Numbers on my MacBook Pro will not open the csv file without an extension. Same issue reported by QA on Windows with IE and Firefox and Microsoft Excel. Same results whether you let the browser open the file in an app directly, or Save As and then open it.

Along with the content-type, the filename and extension needs to be correct.

I fixed this on the server side, by forcing a disposition header the same way send_data does.

respond_to do |format|
  format.html
  format.csv { headers["Content-Disposition"] ||= "attachment; filename=\"#{params[:action] + '.csv'}\"" }
end

Content-Disposition: attachment; filename="index.csv"

So the moral of the story is: don’t be overzealous and stop using formatted routes yet! When you upgrade your app, just remove the formatted routes from routes.rb and everything will continue to work as it should.