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.
EDIT:
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.
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,
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]
end
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]
end
def update_password
user = User.find(params[:id]).update_attributes! password: params[:user][:password]
end
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.
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.
EDIT:
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.
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,
http://www.amazon.com/Rails-AntiPatterns-Refactoring-Addison-Wesley-Professional/dp/0321604814
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 :
and the eventual update_password & update_email would probably look something like that
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 ;)
To add to all of the above, another good book after you get through those resources is Rails Antipatterns. While I do not suggest this book for a beginner as learning the basics of Rails is overwhelming enough, once you get past that stage then this book will be the logical next step in learning how to refactor your code better.
My recommendation. In order to read: