MVC – Post 1 – Rails Controller Reuse

I have too many posts queued up about MVC that I’ve been hoarding in my blog drafts. Rather than sit on these, I’m just going to post small ideas.

The main theme is this: people really don’t understand MVC, and I don’t blame them. It is one of those overloaded terms that has been mangled over many years.

For today’s post, though, I want to cover a small portion of this. The Rails community. Although, they made a lot of progress a year ago, it appears as if that progress has recently slowed. There is also some healthy fragmentation and ‘questioning of the authority’. I think people are comfortable with the framework now and are now learning how to make the next leap forward.

One movement that I find refreshing is the classic re-awakening to the idea that ‘hey, we need better component re-use’ in Rails.

This was attempted back in 2005 and knocked back by DHH here and here.

They are good arguments, but I think the most interesting and best counter-argument is Reusing Rails Controllers is A Good Thing.

Another blog, talking about Cells, a promising project, hits on the same issues with a different solution. This is by Ezra, so you know has some legs.

Finally, the Caboose guys have a proposal as well called Simple Presenters.

Essentially, people are like… “ok ok ok… we’ve tried the old way… lets get something here. We need components”. Of course, who likes to reimplement the same code… over and over again.

This really hit home with a friend of mine. He is working on a new blog engine called Micro and he had a bunch of questions when he got to the comments portion. This is actually really interesting. I mean, if DHH took the blog demo a little further and included comments, the complexity would really expose some issues with the Rails framework.

Here is the issue. You are writing a blog engine. You have posts. Posts can have comments. What if you want to allow a comment author to edit a comment for a post. Bam, big problem. Which controller does that code go into? The post controller or the comments controller? If you go ALL ajax and ALL Restful/Resourceful, then this is elegantly solved. AJAX means that the views on the page are composed and controlled by Javascript. Each separate view (Posts and Comments) can interact with their respective resources on the site. Again, though, this means you have to make the whole site controlled and composed by Javascript code.

Now, if you want to have a NORMAL non-ajax request cycle and your are showing a post, you will have to put the logic in the posts controller. Why? Because in Rails you cannot interact with other controllers while you are already in one. In this case, the Posts controller is the one you are in, so that is where all the code has to go.

My buddy didn’t want to build an all ajax blogging engine, so the ‘code generated’ for the ‘comments’ controller, was basically replicated by hand into the Posts controller. The view code got a little nasty as well.

Clearly, a simple way of having modularity in the framework would solve both scenarios just as well. The good news here is that… just like so many old ideas, people are ‘getting it’ and moving towards better solutions. I suspect that Cells, Engines, or something else will come along and get traction.

Anyways, more posts on MVC later… from other points of view (Cocoa, Win32, Actionscript, etc.)

This entry was posted in General. Bookmark the permalink.

Leave a Reply

Your email address will not be published.