Rails Misapprehensions: Cells don’t break MVC

{{{
I was posting “a stupid simple example how Cells can be used”:http://nicksda.apotomo.de/2010/10/why-rails-controllers-need-a-double-render/ the other day. This controversial post got lots of great comments, thanks to all! While some just questioned Cells and its use, a few *comments really bashed the project* in a very aggressive way. *I like that.*

The rudeness in some sequential comments seems to come from one cause: *Ignorance.* The writings simple proof that the author did *not understand anything about Cells, and MVC in Rails*.

I’ll pick some points from different authors and try to explain.

* “It messes MVC up.”
* “a place that also breaks the MVC framework.”
* “Not only are you abstracting view code out to a place where it simply doesn’t belong, …”
* “I’m not convinced that the benefits of Cells outweigh the complexity they add.”
* “I think you are a nut.”

h3. MVC and Rails

Ok, I won’t explain MVC here again. We already got “great writings about that”:http://martinfowler.com/eaaDev/uiArchs.html – however, there are two points in Rails’ MVC design that might cause confusion.

* The ActionController mixes MVC and the “FrontController”:http://martinfowler.com/eaaCatalog/frontController.html , and this creates the impression that web apps have to be one monolithic controller, one view, and maybe a couple of partials rendered in the controller context.
* *Rails hides rendering*, so in most cases the programmer doesn’t realize templates rendering happens “in” the controller.

Cells are small controllers, derived from @AbstractController@. You can imagine them as *small, separate MVC-stacks between the traditional Rails VC-layer*. There is nothing wrong with that, right, Martin?
}}}

At this point I should stress that there’s not just one view and controller, you have a view-controller pair for each element of the screen

{{{
(Martin Fowler about MVC, “quoted”:http://martinfowler.com/eaaDev/uiArchs.html)

h3. How to break MVC?

If calling @#render_cell@ in the controller is “breaking MVC”, why is there a @#render@, or even a @#render_to_string@ method in the controller? That would mean Rails itself is doing something wrong, as it does rendering _in_ the controller.

It is absolutely ok _in_ the controller *to instruct a separate MVC-component to render* – as long as the controller doesn’t interfere in the rendering process or even shares knowledge about the cells internals.

h3. What is view code?

First, I’d like to emphasize I never said *views should be “_dumb, non-runtime-interpreted view code_”* – WTF? I use helpers, logic, everything in cell views.

Complex forms with dozens of fields, computations and conditions *are surely not “view code” only*, so in my opinion that _should_ be “abstracted out to a place where it simply doesn’t belong”: to a separate component.

However, there is *no need to put every little partial to a cell*. Don’t do that! It is a matter of feeling to perceive when things are getting too complex for a partial mess and should be refactored to a cell instead.

h3. Cells are more complex

This is absolutely true. Cells bring more classes and assets to your project. *It is a new paradigm that wants to be understood*. New programmers might be confused of cells suddenly popping up everywhere in your app.

Cells is a new concept in Rails – *of course it is more complex than odd partials* and helpers accessing global controller variables. It’s a bit like back in the times when OOP became popular and people asked “*Why should I use _objects_ when my simple procedures do all I need?*”. Cells are object-oriented components (with all the stuff we love about OOP, like inheritance) whereas partials are… whatever.

And, don’t forget Cells can be tested in a very simple and clean way, too. *This indirectly reduces complexity*.

h3. You are a nut!

True.

I hope this writing clarifies several misapprehensions I created by posting a stupid simple example. Now, fire at will!
}}}