Today we will talk about code organization in Ruby on Rails projects. As everybody knows, Ruby on Rails is a conventional framework, which means you should follow framework architects’ decisions (put your controllers inside app/controllers, move all your logic into models, etc.) But there are many open questions around those conventions. In this write-up I will try to summarize my personal experience and show how I usually solve these problems.

Here is the list of questions we will talk about:

You have some logic in your view, which uses your models extensively. There are no places in other views with such logic. The classic recommendation is to move this code into a model, but after a short time your models become bloated with stupid one-off helper methods. The solution: pattern Presenter.

Your constructor contains a lot of code to retrieve some values for your views from the database or another storage. You have a lot of fragment_exist? calls to ensure no of your data is loaded when corresponding fragment is already in cache. It’s really hard to test a particular action because of it’s size. The solution: pattern Presenter.

You have a partial, used everywhere on the site. It accepts a lot of parameters to configure how rendered code should look like. The header of this partial, which initializes default values of parameters, becomes larger and larger. The solution: cells plugin.

Scary code, isn’t it? So let’s refactor it using Presenter pattern. I prefer to put presenters into a separate folder app/presenters, so first we should add it to Rails load path. Add this line to your config/environment.rb:

123

config.load_paths+= %W(#{Rails.root}/app/presenters )

Now we are ready to write our presenter (app/presenters/home_presenters/show_presenter.rb):

Please note: you should not do any manipulations on models in presenters. They only decorate models with helper methods to be used inside controllers or views, nothing else. There are several articles describing a Conductor pattern as a presenter, do not repeat their mistakes. See the first link in the list below to get an idea about the differences.

Wow! That’s pretty easy to read and modify. All the logic is in the code now, all the views are easy to read, and moreover: it’s more than easy to test now! I have a little plugin called rspec-cells, and I have committed a patch yesterday to get it working with the latest RSpec. Here is how you spec could look like:

So it looks almost like a classic Ruby on Rails controller spec. I hope to review the code in nearest feature and will send a pull request to the cells plugin author. Of course, if you
found a bug, feel free to contact me.

That’s all I wanted to show you today. I think a Presenter Example project will be updated periodically, so follow it on GitHub, follow me in Twitter or on GitHub to get instant updates. Also take a look at the rspec-cells plugin, maybe you will have some time to make it better.

Great post. I really like the way you organize everything. I have done something similar to a cell (creating a tableless model that a view partial uses) before I realized there is a convention out there already. I am definitely going to try and work this in to my next project.

As for the problem of tracking and matching cache keys in controllers and views we’re using lazy loading of data used in cached fragments with what we call “cache proxy” which is just an implementation of the blank slate pattern.

Unless I’ve missed something, your HomePresenters::ShowPresenter implementation currently displayed in the post still queries the database with each request. You’ve lost the cache fragment checking and, while those queries will only run once per request (by storing the result to an instance variable) will still run once for *each* request – rather than once per empty cache. Otherwise, nice job. :)

Ahh .. you moved the actual query to occur from within the View rather than the Controller. I got it. :-D

The controller simply defines the @presenter, its methods – and thus queries – are only exercised within the view’s cache block. Apparently it’s too early in the morning for me to be evaluating someone’s code. ;)

Yep. Actually I’ve changed a view architecture from push (when you are loading your data in controller and “pushing” it to the view) to pull (when controller performs updates only, but views are “pulling” data by themselves). Here is an article about pull vs. push MVC architecture.

It totally makes sense to *not* have to check for fragments in your controller, and makes it easier if you need to change fragment names. And the cell plugin makes everything fit together even better. Thanks for that!

one thing I especially love in ruby, you don’t have to think about “patterns” at all. You just write ruby code and use one of them almost intuitivelly, without even remembering it got a big chapter in some Big Java/C++ Book and a Captial Letter Starting Name.

Representers, Proxies, Factories, whatever, sometimes what you’ll get is just another level of abstraction, not really useful at all on a second thought. Please, don’t bring that hell to ruby.

Back to subject: Long time ago we had components, but then world was filled with rumours about them being “slow”, and suddenly they fell out of usage and rails core. I yet to see them reintroduced back, in core, lightweight and isolated, but meanwhile both representers and cells functionality could be easily achieved using helpers alone, and I do it all the time.

differences are:

1) you have the same namespace for @vars (but locals are just as good) and helper names. It’s a bad thing because of possible nameclashes, but it’s a good thing for ctags and grep users. <%= video_link @video, :style=>:brief%> is DRY enough

2) you’ll get ActionView::TemplateError with 500 status instead of 404 ActiveRecord::NotFound if you trigger some faulty Model.find in helper and not in controller, but it’s not a big deal and it could be fixed by several plugins.

3) there’s no default place for such helpers, so what i have to do is just to group “presenter helpers” and “cell and decoration helpers” in different helper modules or in different sections of same “resource specific” helper module.

@alexey: one big advantage that Cells (and other ‘heavier’ approaches) have over helpers/partials is inheritance.

The example in this article may not be sufficiently complex to justify for inheritance between Cells, but believe me that this can tremendously simplify an app (compared with complex shared view partials).

This technique is really invaluable as your app grows and you end up with small encapsulated bits of logic that are too big/messy for partials/helpers but are also kind of inappropriate for your models and controllers.

I’m really hoping something like this, or a conversion of Merb Parts, finds its way into Rails 3.

We could actually get rid of HomePresenters::ShowPresenter and use model methods (and scopes) directly. I don’t think Presenter role is to fetch data anyway. Actually Cells do all the work we need here. And if you use decorators (Draper), everything works just fine.

Post a comment

Name (required)

Email (will not be published) (required)

Website

You can use simple HTML-formatting tags (like <a>, <strong>, <em>, <ul>, <blockquote>, and other). To format your code sample use [cclang="php"]$a = "hello";[/cc] (allowed languages are ruby, php, yaml, html, csharp, javascript). Also you can use [cc][/cc] block and its syntax would not be highlighted.