Rails AntiPatterns: Best Practice Ruby on Rails Refactoring (Addison-Wesley Professional Ruby)

Author: Chad Pytel, Tammer Saleh
All Stack Overflow 9
This Month Stack Overflow 2


by anonymous   2019-07-21

The Rails guides explain things like that: http://guides.rubyonrails.org/

But in order for you to really understand how Rails is working - than you need to build an application. That's why most of the tutorials on Rails start with making a project.

This is a free book that will walk you through just about everything you need to know about Rails to get started: http://ruby.railstutorial.org/ruby-on-rails-tutorial-book

In my humble opinion, building an actual application is a great way to learn how all the pieces work together.


Based on your response below, it seems like you are looking for a deep understanding of exactly how Rails works and not just a working knowledge. The only way you can really do this is by digging through the source code - like Archit suggested: https://github.com/rails/rails

You can however get a more advanced understanding of how things work by using this book: http://www.amazon.com/Rails-AntiPatterns-Refactoring-Addison-Wesley-Professional/dp/0321604814. It does a good job of explaining a lot of the "magic" that Rails is known for.

... but you will never know exactly how things work unless you peruse the source.

by anonymous   2019-07-21

You can't move every code in the controller to model. Some code like session handling and request are only scoped to controller. They are not available inside model. Only processing code that is only restricted to model level processing need to be in model.

Following is best book to refactor the rails code,


by anonymous   2017-08-20

I guess that there's no real advantage at creating new actions. And from what I can remember from that book you should stick to the 7 classic actions (index / show / new / edit / create / update / delete) if you can, in order to keep everything RESTFul.

Anyway, the action would probably do the same thing.

a classic update would be :

def update
  user = User.find(params[:id]).update_attributes! params[:user]

and the eventual update_password & update_email would probably look something like that

def update_email
  user = User.find(params[:id]).update_attributes! email: params[:user][:email]

def update_password
  user = User.find(params[:id]).update_attributes! password: params[:user][:password]

When using a single action (the update one) , the only eventual problem would be that a user could update its password via the change email form by changing the html on the page for instance. I don't think that this is a problem as the user has the ability to change his password anyway.

So I would stick to the classic update method.

If I missed your point, please let me know ;)