You might be learning about setting up a Rails Application with Ruby using Active Record! Whew, lots of words.
Let's talk about how our Rails Controller Actions correspond to the HTTP verbs, website URLs, and CRUD actions.
I'm assuming you're using the MVC format of App-writing, which is to say you have Models, Views, and Controllers! Real quick, the Model holds the logic of the App and its relationships to the other models. The Views directory holds the code responsible for what the user SEES on your App site. The Controller's job is to be the middle-man between the Model and View, relaying data from the App to the user, and requesting data from the user to the App.
There are four CRUD actions that are considered necessary for persistent storage application. Persistent storage refers to any data storage device that keeps power after the device is powered off, such as a hard disk or a solid-state drive. In the case of Internet-ing, it's what keeps track of user data, payment info, and other records.
First let's list out the CRUD actions:
C is for Create
R is for Read
U is for Update
D is for Delete
These are basically the bare minimum that an App's model should be able to perform. Like, CREATE an account, READ (show) my account information, UPDATE my account information, or DELETE my account.
Then there are 5 HTTP verbs. This is the TYPE of action performed on any given resource by the server:
GET
POST
PUT/PATCH
DELETE
These verbs correspond to each of the CRUD actions:
- GET is a Read--just retrieving information from server.
- POST is a Create action, making a new entry in the database.
- PUT is an Update action...but for an entire resource, meaning it overwrites the WHOLE entry in the database.
- PATCH is also an Update action, but this time it's just changing one piece of that resource's entry, not the whole thing.
- DELETE is self-explanatory, but I'll write it anyway--it is a Delete CRUD action and it removes the whole resource. (Btw, HTTP stands for HyperText Transfer Protocol, a seemingly vacuous phrase whose meaning doesn't help anyone.)
On top of that, there are 7 distinct Controller Actions, which are defined as METHODS in your resource's controller page:
#index
#show
#new
#create
#edit
#update
#destroy
These also correspond to each of the CRUD actions, I bet you can figure that out. You need to write these as methods in the controller page so that the resource knows what you're talking about when you call those methods. The #index, #show, #new, #edit actions usually point to a page in the Views directory of your resource--then you can code out what you want to SEE when the App calls those methods.
And lastly, this all has to follow RESTful conventions. It stands for REpresentational State Transfer, which just sounds like a random selection of ambiguous words, but don't worry about that since NO ONE ever refers to it that way. Defining the concepts of being RESTful in your code is...in one word, labyrinthine...
...and it's a bit frustrating that we have to deal with 4 different sets of vocabulary in order to instantiate our Rails App, but that's just the way it goes.
What does RESTful mean, though? Well, tough call because researching a concise definition is apparently impossible and cryptic at best, otherwise bordering on the occult. Everything about RESTful conventions is 30 pages long.
Best I can do is this, To be RESTful is to have standardized labelling rules for your URLs that everyone can understand because it's so obvious. Now YOU try to define RESTful conventions in one sentence.
Here's an example. You like Pogs because you're a huge nerd with nostalgia for the 90s. You make an App to catalogue your collection and assert your Pog superiority. You create a Pog RESOURCE with a database. You'll have a Pog model page and a Pog Controller page with a matching Pog view page. I don't want to seeds.rb a bunch of weirdo Pog data, so let's assume that YOU carefully added names and descriptions for each and every Pog in your illustrious collection.
Pog is your resource, this resource has a Model, View, and Controller!
Next you write an index method in your PogController:
This tells the Pog model page to put all the pogs you ever added (in your db file > migrate > bunchanumbers_create_pog.rb file) into an instance variable @pogs for later reference.
Now you'll go to the Views directory, find the Pog folder, and inside there, make a new file called index.html.erb which is what the web App will display when you want to see the index! Rails is so smart, when you call the "#index" method in the PogController, it knows to look for a Pog folder in the Views directory for a file called "index" so it can display(GET) that info.
Inside your Views > Pogs > index.html.erb file, you'll write a simple thing to list all the pogs. Maybe it's like this:
So you launch your localhost:3000 thing in your browser (via rails s) and WHAT IS THE EXTENSION AFTER THAT?! It's /pogs because the RESTful rules would say that "index" is called in the URL by the plural of the resource in which you are listing all those things.
RIDICULOUS ASIDE--((If you wanted an index of all the FROGS you've ever kissed, your page path would be localhost:3000/frogs--calling on the FrogController#index method. That's just how Rails is: the #index method points to the plural form of your model as the URL extension.))--CARRY ON.
Look at this neato cheat-chart I made for this very scenario:
This chart is kind of the summary of what being RESTful is all about...pretty much. When you launch your little localhost:3000 page, you can add /rails/info/routes to the end of that URL and see all the available routes you have thus far in your App. You can also get rid of the paths you're not using by refining your routes page, but that's not what we're here to discuss today.
Now, on this /rails/info/routes page, there's a column called "Path/URL"...really it refers to this SWEET Rails helper method which basically tells you how you can call a URL in your code files. pog_path(@pog) is the path for the #show method in your PogController. An example would be like:
Saying that when you SAVE edits to a Pog (using your strong params private method--read about it here), it'll redirect you to THAT Pog's show page via the pog_path which takes in an argument of THAT instance of the Pog(@pog). Got it?
Couple extra points...you may have noticed that there's no _path for the #create, #update, and #delete actions. This is because those methods will perform an action on the database, but doesn't need to be displayed on the page. The #new and #edit View pages will most likely have fill-out-forms for adding a new Pog, or editing an existing Pog. When your form is submitted, the #create and #update methods will take over to save that entry (#delete will just destroy it from the database).
Also, some of those URLs mention :id in the #show, #edit, #update, and #delete. This is because Rails needs to know WHICH Pog to show, edit, update, or delete. The ID is how Rails will find it in the params hash. Within your methods, you may put something like:
((Real quick, params is like a transient pool of data that refers to the parameters being passed to the PogController via a GET or POST request. More on params))
This sets an instance variable @pog to be a particular Pog found by its ID within ALLLLL the Pogs in params. You'll put something like this inside each method where you want that specific Pog to be referenced.
(((And to be even more concise, you can make a private method:
And then add a before_action :find_pog, only: [:show, :edit, :update, :destroy] line above the list of your non-private PogController methods.)))
Then on your Views > Pog > show.html.erb you can write:
And because you set the @pog variable in your PogController#show method, Rails knows to pull up the name and stats of THAT particular Pog! Wicked smart. You can even add a picture of the Pog in this view page, so people know you have one of the treasured holographic Pog-Slammers that you could win the game with.
So the whole PogsController page looks like this now:
REVIEW
To make a Rails App, you are working with a few different sets of vocabulary: Rails Controller Actions, HTTP verbs, website URLs, and CRUD actions. Refer to that pretty chart in deep teal tones as a nice summary of how those all interact.
Here's the pretty teal cheat-chart again so you don't have to scroll all over the place.
How to Use:
- Use the Controller Action to write your methods in the resource controller page, some of those will have matching View files.
- URL extension column tells you what to write in the address bar of your localhost page to see certain information.
- The HTTP verb is the TYPE of function the server is doing to fulfill your request; some built-in Rails conventions will have a
method:tag and you need to tell it which of these HTTP verbs you're using. (Example:<%= button_to "Add New Pog", new_pog_path, method: :post %>) - And Path Helper tells you how to refer to the URL within your code files for
redirect_to,link_to,button_to, and the like.
Whelp, hope that reading all that mess was helpful! I'm pretty WET behind the ears in the coding arena, so if I got something stupid-wrong, please let me know!
Top comments (0)