
A Fresh Take on Rails Controllers and Views - sant0sk1
http://stephencelis.com/archive/2008/9/rails-controllers-views-and-variables
======
mbleigh
This is actually pretty similar (with a few tweaks) to the plugin I wrote
called fetches: <http://github.com/mbleigh/fetches>. It could easily be
adapted to handle the remaining cases put into example here (in fact, I might
just do that soon).

I like this method (it's how I've been doing it for the past 6 months or so)
because you do the work once and then don't worry about it for the rest of
your controller.

------
nonrecursive
I just posted another technique for DRYing up variable initialization in rails
controllers: [http://www.flyingmachinestudios.com/2008/09/06/dry-up-
contro...](http://www.flyingmachinestudios.com/2008/09/06/dry-up-controllers-
with-params_to_objects/)

The method I used doesn't let you use method names instead of instance
variables, but then again I think it's actually better to use instance
variables. In my code I mostly use instance variables for active record
objects, whereas I use methods galore. The little @ thus helps me find the
active record objects quicker.

------
Spyckie
Pardon me if I offend anyone, but isn't this doing more work for the same
functionality? Can someone give me some insight into why this would be
desirable?

~~~
timr
Because it allows you to maintain clean abstractions, which is essential for
big projects. The ultra-permissive model of programming (the current fad) is
great when the entire codebase can fit in your head, but it fails completely
when you're working with anything larger.

For example, every substantial Rails project I've seen has had views that have
degenerated into messes of bizarre spaghetti logic (which, in turn, interact
with the bizarre spaghetti logic in the controllers, in bizarre, noodly ways).
This is mainly due to the fact that there's virtually no enforcement of
abstraction boundaries in Rails -- views can directly manipulate the models
(whose methods and data are essentially world-writable), which are obtained
via instance variables on the controller, which are always implicitly
available to the view. Mix in things like shared partials, locals and layouts,
and Rails code quickly becomes a maintainability nightmare.

