Two weeks ago I began rewriting REST in Place as a gemplugin for the Rails 3.1 asset pipeline. I just pushed the final version 2.0 to github and rubygems.org and want to give some hints on the new direction of the project.

REST in Place has never been more than a proof-of-concept for me. It worked, pretty well even, so I never bothered much to develop it further, especially since integrating JavaScript code with Rails apps was a bit of a pain. I did only the barest, necessary maintenance and never actually realized that there are people out there using it.

When Rails 3.1 came out, there was finally a way to properly integrate the code into Rails, so I sat down on a weekend and made some massive changes to REST in Place:

  • No more standalone

    Since I don’t think anyone is using it in a different way, REST in Place is now a pure Rails 3.1 gemplugin using the asset pipeline

  • Specs

    To facilitate development of new features and refactoring, the app now has a Jasmine spec suite in the testapp. It can be run by visiting http://localhost:3000/jasmine

  • CoffeeScript

    Because if you’re not using CoffeScript there’s something wrong with you. It makes JavaScript bearable again.

  • Proper CSRF token support

    This was hacky in the past but for a while Rails includes a standard mechanism for providing CSRF information to JavaScript running on the page.

  • Automatic detection of include_root_in_json setting in Rails

    Through the magic of erb and the asset pipeline, REST in Place can detect how you’ve configured ActiveRecord.

  • BC breaking interface changes

    Two major things have changed that might trip you up:

    • The default css class for REST in Place is now rest-in-place and not rest_in_place.
    • Elements with that default class are initialized automatically on document.ready.
    • The jQuery function to intialize elements with a REST in Place Editor was renamed from rest_in_place() to restInPlace().

All this is now available in a nice gem. All you need to do is add gem 'rest_in_place' to your Gemfile and you’re rollin’ (You might want to take a look into the README first).

Now that I have CoffeeScript and specs, development of new features can be done much faster and easier. Some things I have planned:

  • Differentiate between manual abort and a failure
  • Validations/proper error responses
  • Maybe a nicer set of default widgets and UI improvements
  • Rails view helpers

Especially the last two points go a bit against my original intentions for REST in Place, but if it helps more people to use it, hell, why not.

Unfortunately, these changes have come with a very bad timing. One day after I pushed the first beta of 2.0 to github, Ryan Bates did a Railscast about in place editing. While REST in Place is mentioned there, he’s showing Best In Place, a pretty extensive fork of my code that already has most of what I just wrote (asset pipeline, specs) or am going to write (validations, helpers).

Well, as frustrating as that was, I didn’t come as much of a surprise, considered how I’ve neglected REST in Place’s development in the past. I won’t repeat that mistake again, promise.