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.

Quite the contrary, I plan to slowly increase my blogging frequency and extend my topics beyond software.

No, the end of my time at Dortmund Technical University is in sight. Yesterday I registered my diploma thesis which I have six months to work on from now, with a deadline of July 20th.

I’ll probably even blog about my progress here since the topic is something a few web dev fellows might be interested in: A thin Web Application Framework based on Serverside JavaScript

In-Place editing RESTful resources

Writing applications in REST-style encourages an even stricter separation of view and controller logic than the usual Rails’ stack. A key principle is that the client alone should provide the user means to manipulate and PUT/POST data to the server. This is easier said than done in current browsers and with the HTML format (which just wasn’t made for building GUIs, but that’s a topic for another post). AJAX is the closest we can come to this ideal, enabling a seamless transition from a plain view of a resource to a editable form without going through too much pain.

A widely used way to achieve these transitions are inplace editors, made popular by Flickr and supported through nice helper methods in rails. The probem now is that these helper methods were written around, or even before Rails 1.0 with not the slightest hint of REST in them. Planting in_place_edit_for :object, :attribute in your controller creates a set_object_attribute action that finds an object by id, updates only attribute and renders attributes new value as a plain, short string to the client. The client, in this case the XMLHttpRequest, takes that response and puts it in the appropriate place in the HTML document.

There are several problems with this approach:

1. The generated actions are extremely simple and devoid of any form of sophisticated flow control (authorization, exception handling)
2. The generated actions perform a task that can be done in the good old update action and are thusly redundant.
3. Those new actions aren’t at all RESTful.
4. Ideally, no special server side code should be necessary.

While problem 1 can be easily countered by implementing your own version of in_place_edit_for, the real point are the other issues. The update action already performs the task of updating one or more attributes and is equipped with whatever authorization checks are necessary (does object belong to the logged in user?). The update action corresponds to the REST-verb POST and doesn’t violate REST principles.

A solution that solves all these problems would have to look like this (client-side Javascript only):

• The inplace editor posts to the objects url (something like /object/123), passing the attribute to be updated as a HTTP parameter.
• The server sends a response when the update is completed successfully or unsuccessfully.
• In case of an unsuccessful update some form of status could be transferred in the response
• In case of a successful update, the server doesn’t send the updated attributes value, instead the client should GET the object requesting a text/json content-type, extract the desired attribute from the json and update the HTML with its value.

I already tried building my own inplace editor Javascript helper but since much of the functionality of the rails inplace editor depends on the the editor defined in script.aculo.us I gave up. On the one hand the problem wasn’t so pressing that I could justify spending a weekend digging through the source, on the other hand I’d really like to see a good jQuery integration in rails and think maybe I could hit two birds with one stone if I try to go this direction one day.