Destiny Loadouts: Sinatra Flatiron
I’ve now completed my next project for the Flatiron School. The goal for the project was to complete a Sinatra app that uses CRUD and MVC. Although simple on the surface, my app to save loadouts for the video game, Destiny, turned out to be more challenging than I had anticipated. The goal was to give players the ability to save their preferred loadouts in one location. All players can Create, Read, Update and Delete their projects.
Fortunately Sinatra, ActiveRecord and other Ruby gems made the process easier once I got the hang of it, but there are still some aspects that are bit enigmatic. I will ideally walk you through how I set my app up.
Following Proper Sinatra Structure
Thankfully a Flatiron graduate crafted the Corneal gem that provides supporting documentation when one is building a Sinatra app. There were some tweaks that made the app “my own”, but by and large everything you see started off from using Corneal.
Database and Migration
Thankfully ActiveRecord is here to step in and support the migration files. My 2 models were Users and Loadouts as seen below!
Models
Our task was to create models that had the has_many and belongs_to relationships. I decided that a “User has many loadouts” and a “Loadout belongs to a user”. These methods with ActiveRecord made things much easier. Additionally, I could validate certain characteristics of the user to lessen the chance of mistakes. Running the migration through the Rack gem crafted the schema below. NOTE: I did have to rack db:rollback when mistakes were made in the migration files so it was a good learning process to not “hard code” changes in to the schema.
Logic
Unlike the models, the logic of the app was going to be handled by the controllers. The goal was to be delegate separate tasks to separate controllers. Hence ApplicationController, UsersController, LoadoutsController. The Application Controller offers access to GET/POST methods, while the Users Controller and Loadouts Controller perform CRUD actions for the User and Loadouts respectively. The Users Controller and Loadouts Controller inherit from the Application Controller so that they can get access to the GET/POST methods. All controllers were added to config.ru
Routes
The routes were intended to be RESTful and clear to anyone that would be going through the code. They were separated into distinct purposes to CREATE, READ, UPDATE, DESTROY.
Create: Users and Loadouts were very similar in CREATE setup. Grab data from a user from a form through a GET route that then creates an instance of the Loadout object. The object is then stored in the database through POST.
Read: Similar logic for loadouts and users again. A GET route gets things going and a specific loadout is found through its relation to that user. ActiveRecord powers the magic behind this relationship. The find method helps with specificity!
Update: Some deeper changes needed to happen before this could be setup. Note Rack::MethodOverride in the config.ru. Find_by_id helped locate specific loadouts.
Delete: Any object (loadout) is then deleted by using destroy method.
Views
Now we’re going to user .erb files for rendering views. They need clear directions on where data goes from the user. The method attribute in our <form> tag points the form to what request goes to our server when the user clicks submit.
We use a POST request here. The action points the form where it needs to send information. <input> has name attributes because this attribute clarifies how our app identifies <input> data. The cool thing that goes on when dealing with these files is adding “hidden” PATCH and DELETE routes for POST.
Conclusion
This was definitely a challenge and a lot of fun. It’s going to be fun to refactor and improve the overall user experience especially as I dive more into CSS and making the website prettier!
