Sinatra and MVC

For the second project at the Flatiron School’s CS course, I was tasked with producing a fully functional application using the Sinatra Domain Structured Language. Sinatra is a relatively light and agile framework and can be used to create applications quickly and as such, uses a specific patterns.

MVC

The structure of a Sinatra application relies on three main components. The first being a Model. Models are the back-end of your application and are Ruby classes. Per the common pairing of Sinatra and Active Record, a developer will add relational data into these models so they understand how they work with each other. In my program, I had a User model which operated with “has_many” to my other model, for tasks. I also had a Task model, which would “belong_to” a single user.

The second part of the MVC architecture is the View. A view is the front-end and, in essence, is what the user will see. View files have .erb filetype which allows for HTML and Ruby to be embedded (Embedded-RuBy). They include index.erb files which are typically used to show many objects and show.erb files which are more specific to one instance of a model.

CRUD Actions

The Controller is the final piece of the structure and acts as a connection or go-between for the Models and the Views. The controller links specific actions to and directs how instances of the Models are shown, through Views, to the user. They contain all of the routes and are written in Ruby.

All applications, including Sinatra, contain certain core methods for how they interact with data. An important acronym to remember is CRUD, which stands for Create, Read, Update, and Delete. These four actions represent all ways in which data can be acted upon in an application. One can create instances of a model using “get” routes, read them through “post” routes, and update or delete through their own “update” and “delete” routes.

Task Hammer Application

When creating my task management application, it was helpful to follow the straightforward routes and much of the application became fairly scripted. One of the issues I ran into was an unexplained empty hash when trying to instantiate a new task. The new.erb file seemed to be properly set up but when using Pry in the Post route, the param was empty of both keys and the passed in values. I ended up copying and re-pasting some code in my new.erb file (without change) and this somehow fixed the issue. My cohort lead felt that there must have been an issue with some underlying code as nothing in my code was actually changed.

Another issue was that Chrome was having trouble resetting my CSS document so I couldn’t quickly test for aesthetics. This drastically slowed my work toward a more visually pleasing project.

Originally, had anticipated a “due date” with a calendar interface but the data type I used (datetime) was strict about structure of data entered. When data wasn’t entered incorrectly, the value wasn’t passed through on my index page. I also wanted to add a password validation section for the user during sign up to ensure that they didn’t mistype their initial password. These will be added during my next modifications.

Probably my favorite part of the project was wiring up the “Hammer” button for a users individual tasks. The mechanism wasn’t terribly complicated and involved a simple toggle of a boolean to mark uncompleted tasks as completed but it was nice to see the mechanism work from the user stand-point.

Using Sinatra and the more basic structure of MVC has hopefully prepared me for the next section where the same concepts are applied to Ruby on Rails, a more robust framework.