Helpers for common Controller code

Rails
1

Another newbie question: I want to keep business logic out of my
controller. For example I had a routine that did a slightly
complicated computation and it didn’t seem to belong in the
controller. But the calculation has nothing to do with display per-se.
It takes an integer in and returns a different integer.

So I thought to put it in the corresponding helper. Is that the best
practice?

Because I note that helpers are not automatically ‘included’ in the
corresponding controller. I had to add an ‘include’ to the controller
which seemed a bit lame.

2

Not really. In my experience, it works like this:

Keep Controllers and View Skinny. In other words, keep as much code out
of the controllers and view as possible. The controller should only

  1. Make basic calls to model (save, update, custom_method_1)
  2. Assign values to use in the view
  3. Alter the session, cookies, flash
  4. Redirect or render

That is all a controller should do, aka the bare minimum.

Same with the view. A view should only contain

  1. Simple pieces of data to display (set in the controller)
  2. Simple formatting and structure with html

In your quest to keep the controller clean you have some basic options
at hand but the primary place to stick all the stuff you don’t want in
the controller is in the model! Put all the complicated code in the
model and then make simple one line requests and store the return values
in the controller (for display in the view).

In your quest to keep views clean, you have helpers and partials.
Basically, use helpers and partials whenever possible to keep views as
concise and clean of code as possible.

So Basically,

Controller => Lean, View => Lean
Model => Picks up controller’s excess code
Helper => Picks up views excess code

That’s my take anyways.

Pito wrote:

Another newbie question: I want to keep business logic out of my
controller. For example I had a routine that did a slightly
complicated computation and it didn’t seem to belong in the
controller. But the calculation has nothing to do with display per-se.
It takes an integer in and returns a different integer.

So I thought to put it in the corresponding helper. Is that the best
practice?

Because I note that helpers are not automatically ‘included’ in the
corresponding controller. I had to add an ‘include’ to the controller
which seemed a bit lame.

3

In addition to Nathan’s excellent remarks, I’d add:

  1. As much formatting as possible in the stylesheet.

///ark

4

On 12 Dec 2007, at 02:34, Pito wrote:

Because I note that helpers are not automatically ‘included’ in the
corresponding controller. I had to add an ‘include’ to the controller
which seemed a bit lame.

When you see helper, think ‘view helper’. They’re loaded automatically
into templates. They’re not loaded into controller, because they’re
little bits of presentation logic and so don’t belong in the
controller normally.
It sounds like your complicated calculation belongs in a model

Fred

5

Thanks all for the excellent points.

I held back from putting the logic in the model because it really
wasn’t model related. It was more of a ‘business rule’ which takes a
date in and generates two boolean and one date result. The model is a
User table, nothing more.

That’s how I ended up with the helper but as you all say, helpers are
more view helpers - as is evidenced by needing to do an explicit
include in the controller.

6

That’s just it… business rules go in models.

However, it may not go in the User model. Models in Rails are not just
data-access objects - they are your domain models. If this code belongs
to
a User, it goes in the User model.

You can even have models that don’t have a table behind them.

Since I don’t know what this method actually does, I can’t tell you
where it
should go. However, another option is to make your own class and put it
there. The Lib folder is a great place for classes that aren’t models.

lib/utility.rb

class Utility

returns two dates plus the date + 10

def self.do_something_with_date(date)
return 0, 1, date + 10
end

end

That class wil be required automatically by Rails, so you can use it
where
you want. In models, views, etc.

So there’s another option. How you do it depends on what you want to
accomplish. It’s most likely that this method you’re referring to has
some
association with a model, so that’s where I’d put it.

7

I always felt helper should have been a folder inside the views folder
almost. It seems like a common mistake amongst new people to rails to
think helpers are helpers for controllers or models and I can’t blame
them. They need a way of distinguishing helpers and view-centric more.
It’s not really it’s own part of the MVC model yet it gets its own
folder next to the rest of them.

8

I’d go with Brian’s approach, personally. For example, I have a file
in my lib directory that does the rendering of a PDF, which would
otherwise clog up my controlller. I also have Vacation and PTO
calculations in my lib directory for an employee program.

9

One thing I have come to understand which frankly is useful knowledge is
that whenever I tried to “go around rails”, in other words, when I tried
to do things the “non-rails” way I always thought I had a good reason. I
would convince myself that doing it MY way was smarter or better for my
specific condition. What I didn’t realize was that I was just doing
things wrong.

90% of the time it was just me not understand how beautiful and simple
life would be if I would have just not tried to reinvent the wheel or do
thing my way. If I just go with the rails conventions, once I learned
what they were, it ended up making more sense to me that my way even
did. The problem was learning them all because there are so many
patterns and conventions to learn it can drive a man crazy.

I don’t know if this has been any one else’s experience but for me, when
I run into a place where my opinion differs from rails convention, I do
a long, hard look at what I want to do and try to seriously evaluate the
possibility that I am missing something.