Making a simple CRUD Web Application with Ruby on Rails

The finished Events Board application Home Page

Ruby on Rails is an open-source framework for building modern web applications using the Ruby programming language.

In this post we will be making a simple CRUD web app called “Events Board”. The app displays information about an event, where and when it is happening. It will also have a dashboard to add, update and delete events.

We will be using PostgreSQL as our database. You can use any kind of database you prefer. By default Rails configures an SQLite database for you. If you want you can use that. We will also use Materialize CSS for styling our HTML.

First we will start by initializing a new Rails application. To do that you need to have Ruby and Rails installed in your machine. Check out this link to get started: Getting Started with Rails. Once you have everything setup, create a new rails project with PostgreSQL database by typing this on the terminal :

$ rails new events_board -d postgresql

Rails generates all the files needed to run the application. But before we can start the server, we need to configure PostgreSQL by creating a new user for the application. The steps might be different depending on your operating system.

After creating a database user for our application, we need to update our config/database.yml file with the newly created database username and password. After that is done, we can now check to see if everything works, by running our server using this command:

$ rails s

If successful you should see a welcome page with the Rails version and Ruby version. If everything is fine, we can move on to creating our controller. We will create an events controller by typing this on the terminal.

$ rails g controller events

As a convention, we name our controllers as plural and the models will be singular. So, in our case “event” will be the model name and “events” will be the controller.

In the app/controllers directory you should now see a file named events_controller.rb.

Controllers are the centers for our application logic. They handle the interactions between our views and models. To get more information on controllers checkout Action Controller Overview.

We then need to setup a route for our controller. What routes generally do is redirect incoming request to specific controllers and actions . To do that we change our routes.rb file in the config directory to look like this:

Rails.application.routes.draw do

resources :events
root "events#index"

What we are doing here is adding the events resources, which will map requests to the appropriate action in our events controller. We are also making the root of our server the index action form posts.

Now, we generate the event model. The model is the data we will work with, that is persisted in our database. To do that, run this on the terminal:

$ rails g model Event title:string desc:string when:string where:string

To setup our model in the database we need to run some additional commands :

$ rails db:create

This will create the database for our application

$ rails db:migrate

Rails will handle migrations of our tables to our database. If you are interested in finding out more about migrations on rails check out Migrations — Ruby on Rails Guides

Our Finished “EventsController” looks like the code below. An important thing to know is that some of the actions in our controllers are by default linked to our views. For instance, the index action renders the index.html.erb view from our views/events folder. By defining instance variables in our action, we also make them accessible to our views.

The controller actions, I think are self-explanatory. The thing that might be confusing are the two private actions. The “event_params” is a security precaution to only allow permitted parameters to be used. The “set_ui_variables” contains list of strings we make available to views. They are just used to style the HTML dynamically.

All the views for our events controller will be placed in the views/events folder of our app directory. Views generally handle the presentation aspects of our web app. Most of the code we write here is HTML but we also use ruby code to handle dynamic presentation of our data. Also note that the file extension for our views is: <view_name>.html.erb. erb stands for “embedded ruby” and enable us to embed ruby code in our HTML file. For styling the views, we use MaterializeCSS. There are many ways to incorporate it to the project. You can install the gem and import the stylesheet or use CDN or a local copy. The choice is up to you.

We place the HTML for our navbar in the views/layouts/application.html.erb file. This will make sure that the navigation appears in all of our views.

You also notice that an if statement is used at line 20 and 25. What it does is render a “go to dashboard” fab button if we are not on the dashboard page and “add new event” fab button if we are at the dashboard.

The form for our event looks like this :

Here, we are using the form helper to generate a form for our event model. Rails handles most of the heavy lifting for us. One thing to note here, when saving our form we must save it as _form.html.erb. The leading underscore tells Rails that we are making a “partial”.

A Partial template is a smaller version of a view that can be rendered insider other views.

To render the form in our add.html.erb and edit.html.erb we use the render method:

<%= render ‘form’ %>

In our index.html.erb, we would like to display all of the events in our database. Note that in our index action we have an instance variable “@events” with all of the events. So, we use that to loop through and display each event.

This is the tricky part, we want to have a dashboard page to manage our events. The problem is that the dashboard route is not defined. So, we have to change routes.rb to look like this:

Rails.application.routes.draw doget ‘events/dashboard’ => ‘events#dashboard’, :as => :dashboardresources :eventsroot “events#index”end

What we are doing is mapping the GET request to the dashboard action in our events controller. The “:as => :dashboard” part generally allows us to use “dashboard_path” or “dashboard_url”.

Our dashboard view looks like this:

And that’s it! We have made a CRUD web application with Rails. This is what the finished looks like:

The finished Events Board Web App

You will find the source-code for the whole thing at this Github repository



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