Building a Sinatra web application

From this blog posting, I am going to write down some basic key words and definitions to build a CRUD application using Sinatra.

Sinatra

Sinatra is Domain Specific Language implemented in Ruby to build web applications. By using methods like , for instance, "get" and "post", it will instantly transform Ruby application into an application that can respond to HTTP requests.

ORM/ActiveRecord

Object Relational Mapping :to map (or equate) ruby classes with database tables and the instances of those classes with the rows of the table.
ActiveRecord : a Ruby library that connects classes to relational SQL Databases. Essentially ActiveRecord is an ORM that helps to deal with databases.

Rack

a simple interface sits between web frameworks (Sinatra, Rails, etc) and web server

MVC

Models: The 'logic' of a web application where data is manipulated and/or saved.
Views: The 'front-end' web application - this is the only part of the app that the user interacts with directly. Views generally consist of HTML, CSS, and Javascript.
Controllers: The go-between for models and views. The controller relays data from the browser to the application, and from the application to the browser.

naming conventions for an MVC folder structure

erb

.erb file: contains HTML tags and embedded ruby(erb) tags(work with Ruby code); file names, by convention, should match with the action that renders them

controllers

will contain all the necessary routes to help the user sign-in/sign-out, sign-up, and CRUD user's data from the web.

Application Controller

Application Controller represents an instance of the web application when server is running; it is where configurations, routes and controller actions are implements; other controllers use it as an inheritance point to inherit all the defaults and behavior defined in ApplicationController (which inherits from Sinatra::Base)

Database Migrations

by creating tables and schema by using "rake db:migrate" in db/migrate folder, SQLite is usable with seeds data.

shotgun

a ruby Gem to test Rack-based Ruby web application and start Rack with auto code reloading

7 RESTful routes

Sinatra and ActiveRecord CRUD
CRUD
an acronym for Create, Read, Update, and Delete, these are the four basic functions of persistent storage.

Create is implemented in Sinatra by building a route, or controller action, to render a form for creating a new instance of your model.
get '/models/new' -> new.erb -> post '/models'
Read read either all of the instances of a class or a specific instance of a class
get '/models' -> index.erb (to render all of the instances stored in the @models instance variable)
get '/models/:id' -> show.erb (to find the instance of the model with that id number and set it equal to an instance variable: @model = Model.find(params[:id]))
Update To implement the update action, we need a controller action that renders an update form, and we need a controller action to catch the post request sent by that form
Add "use Rack::MethodOverride" line in "config.ru" file to use the Sinatra Middleware that lets our app send patch requests
get '/models/:id/edit' -> edit.erb -> patch '/models/:id'
Delete does not get into its own view page but is implemented via a "delete" button on the show page of given instance
get '/models/:id -> show.erb -> post '/models/:id/delete'

bcrypt gem

It will store a salted and hashed version of our user's passwords(not a plain text version of password) in our database in a column called "password_digest"

has_secure_password

Active Record macro method that works in conjunction with 'bcrypt' gem. It encrypts the plain text version of the password and comes with .authenticate method to see the match of the salted and hashed password from the database.

Session vs cookie

Cookies and Sessions are used to store information. Cookies are only stored on the client-side machine, while sessions get stored on the client as well as a server.

Session

server-side use case for temporarily persisting data while a user browsers the server’s website. Session hash lives on server and web application can access session via any of the controllers at any point in time.

Cookies

Text files stored on the client computer. Server sends a set of cookies to the browser; name, age, or ids etc. The browser stores this information on a local machine and when next time browser sends any request to web server, then it sends those cookies information to the server and server uses that information to identify the user.

Rendering

Rendering allows us to pass instance variables through to the erb file. Rendering a file displays the view without submitting an additional request to the server.

Redirecting

It actually sends a new request to the server. For this reason, Since HTTP is a stateless protocol, we are not able to pass instance variables through a redirect, as those variables no longer exist once new request has been made.

helper method

Helper methods is defined in the controller and can access to the views. It will help not only whether a user is logged in and who the current user is, but also make our code DRY.

rack::methodoverride

The only HTTP methods that HTML form element should allow are "GET" and "POST". For this reason, Rack::MethodOverride is required in order for forms to have a "_method", allowing PUT, PATCH and DELETE actions to function. Don't forget to add the "use Rack::MethodOverride" to 'config.ru' file so that the application will know how to handle patch and delete requests. Put "use Rack::MethodOverride" above "run application_controller" so that the override method works properly throughout the app.