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

Per default, Rails seems to only work with the gems listed in its Gemfile, which means that it starts using webrick. I wanted it to use mongrel, like Rails 2 does and added gem "mongrel" to my gemfile which resulted in rails server just freezing. The cuplrit was some of the weirdest piece of code I’ve ever seen, mongrel’s Mongrel::Gems.require function:

An infinite loop with the only way out being an exception that never got thrown!

This madness was called from mongrel.rb:

Removing these two lines solved the issue. That would have meant patching my gems however, and that smells like something you should not do. The final solution was simple and posted in the comments of the Rails 3 Beta announcement by Juanma Cervera. I just needed to add 3 more lines to my Gemfile:

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.

Dbserialize provides two rake tasks to store your current environments database tables to Yaml fixtures in db/fixtures and to fill the database with these fixtures.

That way it’s possible to store sample data consistently in the repository and for all developers on a project to use common sample data instead of manually generating something on every developer machine or sending database dumps around via email.

Check out the announcement here, the project page here, and the repository on github

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.

• Domain-code in your controllers instead of your models
• Rails choice of inheritance (AR as a base class for models) for implementing AR

Putting domain code inside your controllers is a programmer problem, not a framework problem. I won’t even elaborate this any further.

The other issue is trickier. Not because of technical issues but because there’s a problem with the perception of Rails ActiveRecord. I first didn’t even want to waste my time to write this rant but then I started a comment on one of the postings that turned longer and longer until I decided to make a post of it.

Bill Karwin wrote some observations that I can mostly agree with. There’s one exception though: I don’t see any problem with AR being implemented as a base class for your models.

One perceived problem is a lack of separation of concerns, the idea that you should separate model logic and database logic and that ActiveRecords fails here.

But one must look beyond the separation-of-concerns dogma here and ask what motivates this principle. Mixed concerns lead to confusion, confusions leads to errors and redundance (and thus to more errors). So, the motivation is to maintain a clear view over your methods and to reduce redundance.

Both goals are maintained by Rails although the models contain a mix of model- and database logic. Because most things can be expressed very concisely in Ruby, one line or even no code at all (using the powers of reflection) is enough to achieve what you want. If all your model-functionality and ORM-functionality fit within one page on your screen, the benefit of splitting both into separate modules and/or files becomes too low to justify the cost.

The second problem with inheriting your models from AR::Base is supposedly the tight coupling between your model and your DB-access layer, requiring you to have a database ready for unit testing. If you’ve ever written tests for Rails, you know this is bullshit. Testing is a non-issue and the support for the testing database so seamless that I can’t imagine it being any more simple. One rake task sets up your testing database after a migration, the rest is handled automatically.

Pretending that relying on AR so much for your models is still bad somehow because you might want to change your record-store a some point in the lifetime of your application is nothing but a bunch of bullshit. NO solution EVER will enable you to do THAT in a way that’s so seamless that you’d want to. We’re talking about software here, not lightbulbs that you just screw in. Abstractions are always leaky and talking as if they were not is foolish.

The whole point is that Rails set out to to one thing well, and that is to write web apps in a certain way that has proven to be quite productive and covering the needs of most projects pretty well. You get a lot of comfort following that way but you pay a price if you don’t, namely losing that comfort. People are demanding stuff that Rails never promised to deliver. About their motivations I can only speculate. Maybe they’re just clueless, maybe they just want to make some noise. In any way, they’re hell of a reason to stay away from Digg and Reddit and stick to some bloggers you trust with not wasting your time.

1. Through a dumb count as soon as you query the collection for its size.
   This doesn’t require any additional work but puts quite a load on the database as soon as you have a large list of objects and want to know the size of an associated collection for each object. For 100 posts with comments, this approach would query the database 100 times with SELECT count(*) AS count_all FROMcommentsWHERE (comments.post_id = 1234). This might be okay for single objects which are queried from time to time but not for collections that need to be displayed frequently.
2. Through counter caches that are a bit of a pain in the ass to set up correctly and gave me the fishy impression that they are easily corrupted. Now, I admit that I didn’t spend too long investigating the implementation of the counter cache but after fiddling around with it for an hour before I finally found out how to properly initialize the cache in my migration and after discovering that the cache can only be changed relative to its current content, I left with a bad feeling.
   All this hassle is absolutely unavoidable if you need maximum performance. In this article I’ll use blogposts and comments as an example, though only because this is familiar to many people. A real blog with a bunch of posts on its index page, receiving any considerable amount of hits per day is a bad candidate for the trick I describe here.

In raw SQL, if you want to find out the amount of associated rows in a different table, you use a JOIN, combined with COUNT() and GROUP BY, like this:

Admittedly, this is slower than a counter cache but is not as difficult to set up, doesn’t risk errors due to a corrupt cache and if you chose your database keys wisely it is a pretty nice compromise. When you ask an association collection for its size(), rails checks for the presence of a counter cache attribute in the current ActiveRecord object. If it finds one, it uses its content to return the collection size, otherwise the database is queried.

The catch is now, that in the above example, we inserted a perfectly valid counter cache column into our posts without specifying caching in the association declaration in the class. ActiveRecord inserts that columns content into a comments_count attribute in our Posts but since it doesn’t know exactly what to do with it, it doesn’t cast it into an integer but leaves it in there as a String. That makes size(), or to be more precise, the count_records() method trip with a “String can’t be coerced into Fixnum” error.

To fix this, I wrote an extension for the has_many Association:

Uh, well, yeah, the only change here is the .to_i at the end of line 4 but hey, what did you expect?

Save that in lib/optional_join_counter.rb and extend your association with has_many :whatevers, :extend => OptionalJoinCounter

Now, to get back to the example, imagine we want to use this trick to count our comments. The above SQL can either be written by hand, or with Rails finder options:

Well, after a day playing around with jQuery, I present REST in Place

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.