1. Do the [The Ruby on Rails Guides: Getting Started](https://guides.rubyonrails.org/getting_started.html) project up to section 9.2. It ties together the Model-View-Controller and gives a pretty good overview of the common commands you'll use when using Rails. The remainder of the tutorial covers topics that have not been introduced, like concerns and authentication, so it is hard to understand the big picture. In addition, these sections can be confusing because the instructions do not follow the same copy/paste pattern.
- 2. You should have Rails installed already so section 3.1 might not be relevant. It might still be prudent to run the `--version` commands to check you have everything you need though.
- 3. Make sure you commit to Git regularly so if you run into any issues you can revert to an earlier commit without having to start over from scratch. As a rough guide look to commit at the end of each section.
- 4. Pay attention to any error messages you get as you build the app, even though they'll be unplanned. You'll see all these messages again and again when you're building Rails apps, so it's helpful to start getting familiar with which portions of the message you should pay attention to (and maybe put into Google if you can't figure out what caused it).
- 5. Try to make a mental note of the commands and generators you can use. Rails provides a lot of very helpful generators taking a lot of the pain out of creating different parts of a web application.
- 6. When you're finished, push your code up to [GitHub](https://github.com/).
+ 1. You should have Rails installed already so section 3.1 might not be relevant. It might still be prudent to run the `--version` commands to check you have everything you need though.
+ 1. Make sure you commit to Git regularly so if you run into any issues you can revert to an earlier commit without having to start over from scratch. As a rough guide look to commit at the end of each section.
+ 1. Pay attention to any error messages you get as you build the app, even though they'll be unplanned. You'll see all these messages again and again when you're building Rails apps, so it's helpful to start getting familiar with which portions of the message you should pay attention to (and maybe put into Google if you can't figure out what caused it).
+ 1. Try to make a mental note of the commands and generators you can use. Rails provides a lot of very helpful generators taking a lot of the pain out of creating different parts of a web application.
+ 1. When you're finished, push your code up to [GitHub](https://github.com/).
+
### Additional resources
diff --git a/ruby_on_rails/rails_basics/routing.md b/ruby_on_rails/rails_basics/routing.md
index c3cde81d839..1a2f7b1bbcf 100644
--- a/ruby_on_rails/rails_basics/routing.md
+++ b/ruby_on_rails/rails_basics/routing.md
@@ -25,9 +25,9 @@ This section contains a general overview of topics that you will learn in this l
The most important route in your file is the root URL... where should users be deposited when they land on `http://supercutekittenphotos.com`? Just tell Rails which controller and action to map that route to, and it is so:
-~~~ruby
+```ruby
root to: "kittens#index" #kittens controller, index action (method)
-~~~
+```
Remember, when we say "action" we really mean "the method inside the controller that is called that", e.g. the `index` action is just the `index` method that's defined in the KittensController*
@@ -36,18 +36,18 @@ Remember, when we say "action" we really mean "the method inside the controller
If you recall our earlier discussion about REST, there are basically seven main types of actions that you can (and should) do to a "resource", or an object like a blog post or user... something with its own database model. From that discussion, they are:
1. GET all the posts (aka **"index"** the posts)
-2. GET just one specific post (aka **"show"** that post)
-3. GET the page that lets you create a new post (aka view the **"new"** post page)
-4. POST the data you just filled out for a new post back to the server so it can create that post (aka **"create"** the post)
-5. GET the page that lets you edit an existing post (aka view the **"edit"** post page)
-6. PUT the data you just filled out to edit the post back to the server so it can actually perform the update (aka **"update"** the post)
-7. DELETE one specific post by sending a delete request to the server (aka **"destroy"** the post)
+1. GET just one specific post (aka **"show"** that post)
+1. GET the page that lets you create a new post (aka view the **"new"** post page)
+1. POST the data you just filled out for a new post back to the server so it can create that post (aka **"create"** the post)
+1. GET the page that lets you edit an existing post (aka view the **"edit"** post page)
+1. PUT the data you just filled out to edit the post back to the server so it can actually perform the update (aka **"update"** the post)
+1. DELETE one specific post by sending a delete request to the server (aka **"destroy"** the post)
The highlighted words correspond to standard Rails controller actions!
Each of these represents a "RESTful" route, and so it makes sense that you'll need a way to write these in your Router file so the requests they represent are actually routed to the proper action of your controller (in this case, the "Posts" controller). One way to write them out would be the long way:
-~~~ruby
+```ruby
get "/posts", to: "posts#index"
get "/posts/new", to: "posts#new"
get "/posts/:id", to: "posts#show"
@@ -55,17 +55,17 @@ Each of these represents a "RESTful" route, and so it makes sense that you'll ne
get "/posts/:id/edit", to: "posts#edit"
put "/posts/:id", to: "posts#update" # usually a submitted form
delete "/posts/:id", to: "posts#destroy"
-~~~
+```
Each of these routes is basically a Ruby method that matches that particular URL and HTTP verb with the correct controller action. Two things to notice:
1. The first key thing to notice is that several of those routes submit to the SAME URL... they just use different HTTP verbs, so Rails can send them to a different controller action. That trips up a lot of beginners.
-2. The other thing to notice is that the "id" field is prepended by a colon... that just tells Rails "Look for anything here and save it as the ID in the params hash". It lets you submit a GET request for the first post and the fifth post to the same route, just a different ID:
+1. The other thing to notice is that the "id" field is prepended by a colon... that just tells Rails "Look for anything here and save it as the ID in the params hash". It lets you submit a GET request for the first post and the fifth post to the same route, just a different ID:
-~~~ruby
+```ruby
/posts/1 # going to the #show action of the PostsController
/posts/5 # also going to the #show action of PostsController
-~~~
+```
You will be able to access that ID directly from the controller by tapping into the params hash where it got stored.
@@ -73,12 +73,12 @@ You will be able to access that ID directly from the controller by tapping into
Rails knows you want to use those seven actions all the time... so they came up with a handy helper method which lets you do in one line what we just wrote in seven lines in our resources file:
-~~~ruby
+```ruby
# in config/routes.rb
...
resources :posts
...
-~~~
+```
That's it. That is a Ruby method which basically just outputs those seven routes we talked about before. No magic. You see it a whole lot, now you know what it does.
@@ -86,17 +86,17 @@ That's it. That is a Ruby method which basically just outputs those seven route
With that above line in our routes file, what do our routes look like? If you type `$ rails routes` on the command line, it'll output all the routes your application knows, which look like:
-~~~bash
+```bash
edit_post GET /posts/:id/edit(.:format) posts#edit
-~~~
+```
You can see the incoming HTTP verb and URL in the middle columns, then the controller action they map to on the right, which should all be quite familiar because you just wrote it in the routes file. The `(.:format)` just means that it's okay but not required to specify a file extension like `.doc` at the end of the route... it will just get saved in the `params` hash for later anyway. But what's on the leftmost column? That's the "name" of the route.
There are a lot of situations where you want to be able to retrieve the URL for a particular route, like when you want to show navigation links on your webpage (do NOT hard code the URLS, because you'll be out of luck when you decide to change the URLs and have to manually go in and change them yourself). Rails gives you a helper method that lets you create links called `link_to`, but you'll need to supply it with the text that you want to show and the URL to link it to.
-~~~ruby
+```ruby
link_to "Edit this post", edit_post_path(3) # don't hardcode 3!
-~~~
+```
We're jumping a little bit ahead, but in this case, the second argument is supposed to be a path or a URL, so we use the path helper method to generate that. `edit_post_path(3)` will generate the path `/posts/3/edit`.
@@ -104,9 +104,9 @@ Rails automatically generates helper methods for you which correspond to the nam
Any routes which require you to specify an ID or other parameters will need you to supply those to the helper methods as well (like we did above for edit). You can also put in a query string by adding an additional parameter:
-~~~ruby
+```ruby
post_path(3, :referral_link => "/some/path/or/something")
-~~~
+```
Now the `:referral_link` parameter would be available in your `params` hash in your controller in addition to the normal set of parameters.
@@ -114,7 +114,7 @@ Now the `:referral_link` parameter would be available in your `params` hash in y
Just to drive home that routes correspond directly to controller actions, a sample controller which would fulfill the above routes generated by `resources :posts` might look like:
-~~~ruby
+```ruby
# in app/controllers/posts_controller.rb
class PostsController < ApplicationController
@@ -158,7 +158,7 @@ Just to drive home that routes correspond directly to controller actions, a samp
# destroy it. Once that's done, redirect us to somewhere fun.
end
end
-~~~
+```
Remember that you can run `$ rails routes` in the project directory to see all of the routes with their corresponding controllers and actions.
@@ -166,18 +166,18 @@ Remember that you can run `$ rails routes` in the project directory to see all o
Sometimes you just don't want all seven of the RESTful routes that `resources` provides. Easy, either specify just the ones you want using `only` or just the ones you DON'T want using `except`:
-~~~ruby
+```ruby
resources :posts, only: [:index, :show]
resources :users, except: [:index]
-~~~
+```
### Non-RESTful routes
Of course, you don't have to do everything the RESTful way. You probably should, but there are times that you want to make up your own route and map it to your own controller action. Just follow the examples we gave at the top for RESTful routes:
-~~~ruby
+```ruby
get '/somepath', to: 'somecontroller#someaction'
-~~~
+```
... of course, the `config/routes.rb` comments should be helpful to you here as well.
@@ -186,24 +186,27 @@ Of course, you don't have to do everything the RESTful way. You probably should
You should have a good sense of what's going on in the routes file by now but probably also have plenty of questions. The Rails Guides to the rescue!
+
1. Read the [Rails Guides chapter on Routing](http://guides.rubyonrails.org/routing.html), sections 1-2.5, 3.1-3.4, 4.6, and 6.1
-2. Watch this [Wonderful explanation of how REST and HTTP works](https://www.youtube.com/watch?v=Q-BpqyOT3a8). You can follow the tutorial using `curl https://api.github.com`.
+1. Watch this [Wonderful explanation of how REST and HTTP works](https://www.youtube.com/watch?v=Q-BpqyOT3a8). You can follow the tutorial using `curl https://api.github.com`.
The Postman Chrome Extension shown in the video is deprecated. Use the native [Postman App](https://www.postman.com/downloads/) or use the web version.
+