4 ms·

A Fresh Take on Rails Controllers and Views

9 points by sant0sk1 18y ago

nonrecursive 18y ago
I just posted another technique for DRYing up variable initialization in rails controllers: http://www.flyingmachinestudios.com/2008/09/06/dry-up-controllers-with-params_to_objects/ http://www.flyingmachinestudios.com/2008/09/06/dry-up-contro... 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 18y ago
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 18y ago
  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.
mbleigh 18y ago
This is actually pretty similar (with a few tweaks) to the plugin I wrote called fetches: http://github.com/mbleigh/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.

9 points by sant0sk1 18y ago

I just posted another technique for DRYing up variable initialization in rails controllers: http://www.flyingmachinestudios.com/2008/09/06/dry-up-controllers-with-params_to_objects/ http://www.flyingmachinestudios.com/2008/09/06/dry-up-contro... 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 18y ago

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 18y ago
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.

mbleigh 18y ago

This is actually pretty similar (with a few tweaks) to the plugin I wrote called fetches: http://github.com/mbleigh/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.