Working with databases is hard, so we use Models to simplify the work
ActiveRecord provides us with methods to easily work with the database
We can use rails console as an enhanced IRB environment that includes our Rails app classes
IN views/tweets/index.html.erb
Where does @tweets come from?
We know it is an array of Tweet instances
We know Tweet instance responds to methods for its attributes (e.g. .body and .handle)
We still don't know how @tweets gets initialized...
Controllers
Controllers talk to the database, and pass data to the views
They use Models to talk to the database
They use instance variables to pass data to the views
Controllers are custom Ruby classes that inherit from ApplicationController, just like how Models are custom classes that inherit from ActiveRecord::Base
Controller for each Resource
The same way we have a Model for each resource, we have a Controller for each resource
For the tweets resource, we have a Tweet model class, and a TweetsController controller class
For the users resource, we have a User model class, and a UsersController controller class
Note the plurality on models (singular) and controllers (plural)
How does it all fit together?
URL -> Controller -> Method
When you visit /tweets, it instantiates the TweetsController class and calls the index method on it
When you visit /tweets/new, it instantiates the TweetsController and calls the new method on it
When you visit /users/1/edit, it instantiates the UsersController and calls the edit method on it
Actions
Inside a Controller class, the methods (e.g. index and new) are referred to as actions.
Code-Along
Let's take a look at the code inside app/controllers to get a better sense of what Controller code looks like.
The Map
URL
Action
/tweets
TweetsController#index
/tweets/new
TweetsController#new
/tweets/1
TweetsController#show
/tweets/1/edit
TweetsController#edit
Routes
These mappings of a particular URL pattern onto a particular Controller and Action are known as routes
Routes are how users access your applications (think of them as gateways into your database)
Eventually, these mappings will become second nature
In the meantime, you can use a command in your terminal to see all the routes:
$ rake routes
rake routes
$ rake routes
PrefixVerbURIPatternController#Action
tweets GET /tweets(.:format) tweets#indexPOST /tweets(.:format) tweets#create
new_tweet GET /tweets/new(.:format) tweets#new
edit_tweet GET /tweets/:id/edit(.:format) tweets#edit
tweet GET /tweets/:id(.:format) tweets#showPATCH /tweets/:id(.:format) tweets#updatePUT /tweets/:id(.:format) tweets#updateDELETE /tweets/:id(.:format) tweets#destroy
Q. So, where did all these 'routes' come from?
A. Rails Scaffolding created them for you, in the routes.rb file. A set of routes were created for each resource.
routes.rb
Rails.application.routes.draw do
resources :tweets
resources :usersend
routes.rb
In the routes.rb file, the resources method allows you to create a collection of routes in one line
Just by typing resources :tweets, Rails will create all of the routes associated with the tweets resource (e.g. everything we saw in the rake routes output)
The resources method is the simplest way to create a set of CRUD routes for a given resource
When you scaffold a resource, it places the resources declaration for the resource in the routes.rb file automatically
The Complete Picture
RECAP
The collection of Model instances (e.g. @tweets) is populated into views by Controllers
Controllers are custom classes that inherit from ApplicationController
Routes are the mechanism through which a given url (e.g. /tweets) invokes a particular method (e.g. index) in a controller (e.g. TweetsController)
Routes are declared in the routes.rb file, using the simple resources method.
Code-Along
Let's modify the Twitter app to change the @tweets data set in the Controller before it passes it along to the view.