After reading about many of the features planned for Rails 4, the one I was most excited for was form signing. It wasn’t an officially planned feature, but it was discussed here by Yehuda Katz. Some time ago DHH mentioned that it wasn’t going to end up in Rails 4. I’m not really sure why, but I guess it makes sense. It certainly isn’t a one size fits all approach to dealing with user input. I do, however, think it is a great idea for a 3rd party gem. Such a good idea, that I decided to write it.

signed_form version 0.0.1 is available in the usual way from RubyGems and the project itself is on GitHub.

There’s plenty of information in the README about it. But in short it generates a list of fields from those that you place in your form. It then signs those fields to be submitted along with the form. On the receiving end, if the signature of those fields is valid the controller will then permit those attributes using strong_parameters under the hood.

This means that for the most part you only have to build your form and stop worrying about slicing user input in the controller. Of course like I said this isn’t one size fits all and you’ll probably not be able to use it for all forms. There’s also a couple of caveats that are discussed in the README. But I think that for a lot (most) forms it will be a great fit and hopefully save you a lot of time and hassle.

It is a new project, so if anyone wants to contribute or has any other feedback it would be much appreciated.

I’m pleased to announce that today I’m releasing the Handlers-js gem (Github repo).

Handlers-js builds on a technique I talked about in previous posts. Now for your convenience it is available as a gem for the Rails asset pipeline. Also included is out of the box support for Turbolinks which is turned on by default in the upcoming Rails 4.

With handlers, you write your HTML like this:

1
2
3

<span data-handler="TypeAhead" data-typeahead-url="..." data-typeahead-property="..." data-typeahead-value="...">
  ...
</span>

A while back I wrote a blog post about API versioning and Rails. Well I’ve made a number of improvements to the gem. Including adding a very simple DSL, a generator to bump your controllers (who wants to do that manually?), and a module to simplify the format from the Accept header if you use Rails responders.

Assumptions api-versions makes:

• You want the client to use headers to specify the API version instead of changing the URL. (Accept header of application/vnd.myvendor+json; version=1 for example)
• You specify your API version in integers, v1, v2, v3, etc. If you need semantic versioning for an API you’re likely making too many backwards incompatible changes. API versions should not change all that often.
• Your API controllers will live under the api/v{n}/ directory. For example app/controllers/api/v1/authorizations_controller.rb.

The rest of the README follows. The source is of course located at http://www.github.com/erichmenge/api-versions.

One of the great additions to Rails was CoffeeScript. It has been great to work with. If you’re new to Rails it might be a bit confusing though. Every time you create a controller for instance, you get these .coffee.js files generated. You probably discovered that all these files are loaded regardless of what controller you’re on though. It is nice to have all the generated javascript separate from your HTML files. What isn’t so nice, is you’re executing code that is almost completely non-applicable to the current view that is rendered most of the time. Often there is only a small fragment fragment of code that actually matters for that view.

Rails provides no guidance in this department. I’ve seen people suggest things like:

1
2
3

$ ->
  if $(".posts").length() > 0
    doSomeThingCool()

This quickly gets a bit messy though. I’ve implemented a different approach.

UPDATED: Code improved based on feedback from David Workman.

I’ve recently begun working on a mobile application using Backbone.js and jQuery mobile. I also wanted a way to easily split up the code into many files and have them be concatenated at the end. For this task I chose Sprockets, which has the added benefit of working great with Rack applications, which I’m using with Pow for development.

UPDATE: I’ve created a utility called Backrack to generate the the structure for the mobile app. With it, creating Backbone.js powered mobile apps is a breeze. A few simple commands and you’re ready to go:

1
2
3
4
5
6

gem install backrack
backrack new my_app
cd my_app
backrack generate view users/new
backrack generate model user
backrack generate collection users --model user --url http://mysite/api/users

I recently updated a Ruby gem I had created for API versioning in Rails. It is still only version 0.0.4, and it is a pretty straight forward and simple gem. But if you’re interested in running multiple versions of an API in your application, this gem might be helpful to you. It allows you to inherit resources from prior versions of the API in your routes file. You’ll still need to copy the controller files over, but at least it keeps the redundancy out of your routes file. I think I’ve done a pretty decent job of documenting it in the README, so I suppose I’ll just include that here. The project is available at https://github.com/erichmenge/api-versions. It is also on Rubygems of course.

I wrote it for my own projects, but hopefully someone else will find it useful as well.