Rails and Resources, Part 1

This week, we began studying Rails. Compared to last week, I didn't run into any bumps between UNIX/Window differences thus far, so that was a relief. My PSQL is set up correctly (though I've yet to dig through security allowances and authentication more than I needed to - I'm almost sure that we'll be going through that, though), and I'm able to install rails with some ease.

This is probably the part that I had a few hiccups compared to the easy installs the UNIX terminals had, but this was all just because I didn't have all the installations ready.

Basically, I installed ruby, but not particular gems and additional devkits that were necessary to set things up for installing rails. Luckily, when I tried to install Rails, the error messages were -very- helpful (it's important to read them!) in pointing me at what I needed to do next. First, I needed to install JSON via gems, but then when I was told I couldn't install JSON via gems, they pointed me to make sure I had the devkit in my PATH if I installed it already. I don't think I installed the ruby devkit.

First things first, I needed to get the Ruby Devkit 's latest version. Once that was done, I ran the gem install command for the JSON version I needed (ruby gems will tell me what the exact version and command I needed once I tried to install rails on failure). After that, it was a simple matter of using 'gem install rails' and I was set.

Rails is fairly easy to comprehend, given that we spent the last week working with the stuff 'under the hood' - it makes all the things we did in Sinatra and PSQL so simple and straightforward, and there's lots of ways to shorten the process of pulling database entries onto a website.

Two of the most crucial things we had to consider however, was how the entire Rails system worked from request to response, and the other was the Seven Route Resources (tm?).

First, the Rails system from Request to Response: assuming the database is already made:

From the Browser, we make a Request to the App Server. It receives the path specified in the request, and properly routes it through a controller. The controller may instantiate the Model, which allows it to pull, change and request information from the database. From there, it renders the view based on what information it has and has been given, which becomes the response sent through the App Server and back to the Browser which displays the response, likely as an HTML file.

Browser refers to the user, or the browser who is navigating the html page and making the request.
The command 'rails s' boots up the App Server.

Routes refers to the routes.rb. It takes the Path of the url and accordingly performs the correct action via the controller.

Controller refers to the tablename_controller.rb. This is where the various actions are defined (akin to methods). What it exactly does depends on what Route is taken in the previous step. Primarily, it will set instance variables for the Model and View to use. It can pull/send database records/changes on request based on the Route via the Model, and render the View with the information it has before sending the response to the request back to the Browser. In the case of a redirect (HTTP code 3xx), it will not use Model or View and return the redirect response to the browser, which will initiate a new request to render the target URL.

Models refers to the modelname.rb file. When it gets instantiated, it's akin to using "tablename = Class.new". As classes in Rails in this case inherit ActiveRecord::Base, the object 'tablename' here is of type ActiveRecord and has access to the specific commands we use in Rails. Depending on what the controller requests, it may pull some information (.find, .where), pull all the information (.all), create a new entry (.new, .create) with the associated database table (which the Model is named after).

View refers to the .html.erb file. This is where the html.erb file containing all the text, code, and variable references are laid out. The Controller will read and render when it requests for it.

DB refers to the database.



====
Browser --request--> App Server --> [Rails Stack: Route --> read path --> Controller --> Proceed based on path:
====
Controller <--instantiates and requests based on routed path--> Model <--pull, change, create entries--> DB

AND/OR

Controller -- Reads based on route -->View --Rendered --> Controller --> App Server --returns response --> Browser

OR

Controller -- Receives redirect route --> App Server --returns response --> Browser
 ====

That sums up the entire process. Hopefully, this will help others understand as well. Thanks to the instructors for being patient and making this clear. Next part, I'll describe the Actions/Paths associated in the Resources in Rails.