Ruby Rails RESTful & CRUD Quick Reference
Tags: ruby, rails, controllers, productivity
Published: 2020-02-29 16:17:01

---
title: Ruby Rails RESTful & CRUD Quick Reference
published: true
description: Quick reference guide for setup and use of controllers in a ruby app
tags: ruby, rails, controllers, productivity
series: Software Engineer Quick Reference Guides
---

# Rails RESTful 
## Generate function
### Rails g model
``rails g model tablename column1 column2``

Tablename, this needs to be what your model is going to be called. 

Rails 6 has plurallize built in so it'll make the model singular but keep the table plural as is best practice. To set them as other data types just state them as other than a string.

``column1:integer``

All the useful data types, there are more but these will get the job done most of the time.
- string
- integer
- float
- timestamp

### Rails g controller
``rails g controller ControllerslName controller actions``

ControllersName needs to reference the model with the following convention 

``ModelsController``

The controller actions are, by default, empty unless you specifiy them. The convention is the following order 

``index show new edit create update destroy``

This will setup those seven routes in ``routes.rb`` as well create app/views/model and .html.erb files for each route

### routes.rb
after runing ``rails g controller`` command like above the routes.rb file will be created with the following boilerplate code
```ruby
Rails.application.routes.draw do
  get '/models/index'
  get '/models/show'
  get '/models/new'
  get '/models/edit'
  get '/models/create'
  get '/models/update'
  get '/models/destroy'
end
```
This is fine as is or it can be refactored down to a single line ``resources :models``. 

If you only generate a controller action as needed then the routes and view file will need to be created manually as you go. This may be a better method of going about building out the basic functionality of your web app to be honest as there will be no routes that are unknown to you as the dev.

_side note:_ I didn't follow that pattern of build only what you need as you go, and in the last code challenge I found myself lost quickly.
While troubleshooting I knew there was more in the app than I had full understanding of. 
In the future I will build controller actions out 1 at a time as I need the functionality and route.

To take advantage of ``resources :models`` with only specific routes (the buils it as you go method) there is a way to have rails only create those routes you need.

```ruby
resources :models, only: [:index, :show]
``` 

you can add to the list within the brackets as you build out your web app.

### controller action methods
For every route you need a controller action method. These live in the ./app/controllers/models_controller.rb file. Each model has a controller and they each inherit from application_controller.rb. 

**This is a great file to place repeated logic in different models, just have the method in the application_controller.rb and all models will have access to the method**

#### index
```ruby
def index
  @models = Model.all
end 
```
For index the only thing really needed is ``@models = Model.all`` as this will provide the logic needed to be able to access all data in the dB table for the model. This is useful as an index web page that lists out everything - table of contents, or all users, or all whatevers.

#### show
```ruby
def show
  @model = Model.find(params[:id])
end
```
This ensures that a show page for any indivdual record in the dB table for the model can be accessed. This line of code is actually used often in other controller action methods and can be moved to a ``before_action`` macro (more on that later though).

#### new
```ruby
def new
  @model = Model.new
end
```
Another brief bit of logic that makes sure the page will send a ``.new`` command to the dB to kick off the creation of a new record. Additional logic could go here that would pull in more logic for a New page in the browser.

#### update
```ruby
def update
end
```
This is the best place to any logic for creating, editing, or updating a record. Placing validation logic here will ensure that when you create the update view and use ``form_for`` that a submit button will change it's wording to match the actual action. This is super cool rails magic as it will first check if the record id exists, if it does then it'll pull in the record data to your ``form_for`` form and the submit button will say 'update'. If there is no record then the ``form_for`` form will be empty and the submit button will say 'create'. Also if all routes to any of these actions (craete, or update) are set to the same route than rails again will make sure everything works as expected. Basically just user the update route and rails will take care of it.