Static Request/ Routes/ HTTP workflow/ Database Migration

To get Rails saying “Hello”, we need to create at minimum a route, a controller with action, and a view. A route maps a request to a controller action. A controller action performs the necessary work to handle the request and prepares any data for the view. A view displays data in a desired format. Routes are rules written in a Ruby DSL (Domain-Specific Language). Controllers are Ruby classes, and their public methods are actions. And views are templates, usually written in a mixture of HTML and Ruby.

Before we dive into the code and routing configurations, it helps to know how HTTP works at a high level. Below is the flow that takes place when a user attempts to go to a page on a Rails application:

  1. A URL is entered into the browser; this is the HTTP request
  2. That request is sent to the server where the application’s router interprets the request and sends a message to the controller mapped to that route
  3. The controller communicates with the view file mapped to the controller method
  4. The server returns that HTTP response, which contains the view page that can be viewed in the browser

Adding a route to our routes file,

Rails.application.routes.draw do
get "/articles", to: "articles#index"
end

note: Anytime we make routing changes we need to restart the Rails server!

The route above declares that requests are mapped to the action of . To create and its action, we'll run the controller generator:

rails g controller Articles index --skip-routes (since we already have an appropriate route)

This will generate several files, but the most important at that point is the controller file at app/controllers/articles_controller.rb:

class ArticlesController < ApplicationController
def index
end
end

The action is empty. When an action does not explicitly render a view (or otherwise trigger an HTTP response), Rails will automatically render a view that matches the name of the controller and action. The action will render by default. Add:

<h1> Hellow world </h1>

to see the text on your localhost/articles!

note:
Explicit rendering — for explicit rendering, Rails lets you dictate which view file you want to have the controller action mapped to.
Implicit rendering — for implicit rendering, Rails follows a standard convention that automatically looks for the view file with the same name as the controller action.

To define a model, use the model generator:

rails generate model Article title:string body:text

note:
Model names are
singular because an instantiated model represents a single data record. To help remember this convention, think of how you would call the model’s constructor: we want to write , not .

Database Migrations

Migrations are used to alter the structure of an application’s database. In Rails applications, migrations are written in Ruby so that they can be database-agnostic.

class CreateArticles < ActiveRecord::Migration[6.0]
def change
create_table :articles do |t|
t.string :title
t.text :body

t.timestamps
end
end
end

The call to specifies how the table should be constructed. By default, the method adds an column as an auto-incrementing primary key. To run the migration:

rails db:migrate

Showing a List of Articles:

In app/controllers/articles_controller.rb :

class ArticlesController < ApplicationController
def index
@articles = Article.all
end
end

in app/views/articles/index.html.erb :

<h1>Articles</h1>

<ul>
<% @articles.each do |article| %>
<li>
<%= article.title %>
</li>
<% end %>
</ul>

The above code is a mixture of HTML and ERB. ERB is a templating system that evaluates Ruby code embedded in a document. Here, we can see two types of ERB tags: and . The tag means "evaluate the enclosed Ruby code." The tag means "evaluate the enclosed Ruby code, and output the value it returns." Anything you could write in a regular Ruby program can go inside these ERB tags, though it's usually best to keep the contents of ERB tags short, for readability.

hint: Since we don’t want to output the value returned by , we've enclosed that code in . But, since we do want to output the value returned by (for each article), we've enclosed that code in .

Here’s what happens:

  1. The browser makes a request: .
  2. Our Rails application receives this request.
  3. The Rails router maps the root route to the action of .
  4. The action uses the model to fetch all articles in the database.
  5. Rails automatically renders the view.
  6. The ERB code in the view is evaluated to output HTML.
  7. The server sends a response containing the HTML back to the browser.

SOFTWARE ENGINEER — WEB DEVELOPER WITH HEART FOR FRONT-END, MINIMALISM AND RASMENTALISM.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store