Rails Cells: Component-Oriented Development for Rails

The aim of Rails Cells is to "bring the benefits of component-oriented development to the Ruby on Rails web application platform". A cell is a sort-of lightweight controller with an associated view that can be embedded into a website (similar to Smalltalk's web application framework Seaside).

So what's wrong with Rails' existing facilities? According to Mike Pence's blog:

Many Rails projects resort to partials with before_filters to fill the gap, but such an approach has its own problems. Shared partials bloat the application_helper with their initialization code, and since they can see all of the instance variables of the controller methods that precede them—an unfortunate design decision, I think—they tend to be rife with dependencies on the controllers that initially hosted them, the views that initially contained them, and the helpers that they depend upon. It is rare, in my experience, to find substantial partials that are readily sharable without considerable, painful, debugging to extricate them from the web of dependencies they weave.

Contrary to the relation between a controller and its view, the controller's instance variables are not automatically shared with a cell but need to be explicitly passed to it. This allows for Cells to be independent from a specific controller and therefore to be both reusable and shareable.

We talked to Nick Sutterer, one of Cells' developers, and asked him about the status of Cells' development:

We're working on an improved version of cells, but are rather busy with our daytime jobs (typical excuse for any open-source developer). Fortunately, some folks from the community have submitted patches or helped with documentation—especially Mike Pence is worth naming here. With the 1.0 release we intended to mark the plugin as useable and signalized that the API is quite stable and won't change significantly in the near future.

The next version will be fully Rails 2.0 compatible. There are some problems with helpers here. Another issue is engines [the Engines plugin enhances Rails' own plugin framework to make it easier to share controllers, helpers, models, etc. in plugins] support in cells. Personally we love engines. Great work, James. Nevertheless people seem to be afraid of it, so we have to make it optional for users. I really love the idea of putting cells into engines, it helps me to maximize the modularity of my applications. There's also a problem with the forgery protection in cells, in combination with AJAX. As cells are perfect for the use with AJAX we will spot-and-fix this in the next version. Promised.

We were also interested to hear how Cells has been adopted in the Rails community so far:

There is noteable interest for cells in the rails community. Folks come to our IRC channel or use the mailinglist regulary to ask questions about how to integrate cells into their projects. Cells introduce a new component orientation into rails - it will surely take a while till developers understand the power of it and use it in bigger applications. My co-developer Peter Bex came to cells and implemented a project called formbuilder with it. I am busy with my upcoming plugin Apotomo based on cells. It introduces stateful components in Rails. And it's hot. I'm sure there will be more noteable projects with cells. Maybe I should open a "Success Stories" blog on the cells page?

To learn more about Cells, check the Cells website or take a look at the Cells documentation.