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.

The definition of forms for editing inline-content is now separated from the Code that deals with Ajax and editing state. This makes it very easy to extend REST in Place with your own Editors.

I also decided to keep the jQuery backwards compatibility for a bit longer.

Check out the changes at http://github.com/janv/rest_in_place.git

In November I got some pull requests for REST in Place which I didn’t get to really have a look at until last week. I haven’t really touched REST in Place in ages and wasn’t really aware that it was that popular. It has 72 followers and 11 forks on github and who knows how many other people are just silently using it! So, I merged in the contributions and dealt with some issues in the tracker and thought about how to go on.

REST in Place originally was a mere proof of concept and one of my first projects in JavaScript and jQuery. I have since written a lot more complicated applications and even a diploma thesis on JavaScript and the old code just isn’t up to my standards anymore. Additionally I have received several pull requests for textarea support which all couldn’t be merged because they were just copypasted and modified a little from the input-tag version. The only solution was a complete rewrite and that’s what I did. While the plugin still works the same way, the code is properly split up and more modular now. This enables easy extension and maintenance from now on and hopefully quicker development from me and better patches from all users.

This new development has some drawbacks too, unfortunately. This massive improvement will only go to the jQuery version of REST in Place. Since I don’t know much about Prototype or mootools, I can’t support both versions anymore. If someone is willing to work with me on this, I’ll happily accept their contributions but I can’t do this on my own. If anyone is willing to do so, please reply in the comments, so we can work out a plan. I want to keep all three versions as similar as possible, this means the Prototype and mootools versions should follow the same object-oriented structure as the jQuery version.

One last thing: I will support jQuery < 1.4 until 1.4.1 comes out. 1.4 introduced some very nice changes which I’d like to make use of but since 1.4 seems a little buggy still, I’ll continue to support the older versions for a little while.

He also was so kind to improve the included testapp a little.

Please check out the changes at http://github.com/janv/rest_in_place/tree/master and on the project page.

Convenience vs. validity

Regarding the project page.

In itself it’s kinda pointless since it contains nothing more than the readme which you can also see in all its glory over at github. But it’s invaluable for feedback through the comments. Wincent Colaiuta posted a remark about the standards compliance of the custom attributes RIP uses, which I have to admit is kinda valid:

Haven’t looked at the code yet, but I like the idea very much.

The only problem is those non-standard attributes that you’re jamming into the divs and spans are not valid HTML (well, I admit, I only checked them with an XHTML validator; I don’t actually know if they’d be considered valid for any particular other version of HTML or XHTML).

For me that’s a bit of a show-stopper, as I don’t want my pages spitting out validation errors if anyone feeds them into a validator.

Other than that, looks like a great idea though.

However it also kinda isn’t.

I replied:

I understand your concern but let’s be honest for a minute ;)

These additional attributes might be undefined in XHTML but are syntactically correct and will just be ignored by browsers. They provide a very convenient and concise way of specifying how to edit the fields. They pose no actual harm to a user’s browsing experience. Neither directly (in the form of malfunctions) nor indirectly (like what the widespread use of really ill-formed HTML did to web development in the past).

As a computer scientist I understand the desire for absolute correctness. But as an actual application developer, my users are my target audience, not fellow nerds who like feed my pages into validators (no offense). A little pragmatism can’t hurt once in a while if you want to get things done.

Is this a case of correctness for the sake of correctness? Or were it little steps like this what led us to the browser wars and IE6? Should REST in Place give up convenience for the sake of correctness? How do others deal with inofficial attributes. I know a lot of people and a lot of situations where they saved developers a lot of time and headache.

I’ve updated the README and the project page with the new information.

I’ve also published my dbserialize plugin at Github.

I fixed that problem yesterday in both the jQuery and the Prototype version (both included in the plugin.)

Check it out on the REST in Place project page.