Djs Have Many Playlists

When my cohort lead tasked us with thinking of examples of has-many/belongs-to relationship two weeks prior to project week I must admit I struggled to come up with a topic. After much thinking, my mind wandered to my college radio days where uploading a document of your radio show’s playlist was quite a difficult task to do. We had to go through different people in order for it to be posted, and since some of the radio shows revolved about picking music on the spot, keeping track of playlists was an issue. I then decided to try my hand at making a Sinatra Application where different Djs are able to login and create and edit their own playlists. It was a great way to get familiar with ActiveRecord, SQL, HTTP requests and restful routes.

Setting Up Sinatra

For this particular project I used the Corneal gem, created by a former Flatiron student and updated by my cohort lead. Corneal sets up the file structures you need in order to start building a Sinatra App. I also added the sinatra-flash gem for flash messages and the dotenv gem to use an environment variable to further secure the sessions secret key.

Creating Database Tables, Migrations and Models

I created two models, a Dj class and a Playlist class. I had both classes inherit from ActiveRecord::Base and set up the has_many belongs_to relationships that exists between them. Dj has many playlists and and a Playlist belongs to a dj. Similarly, inside the Dj class I called the has_secure_password method that is available to us thanks to the bcrypt gem and allows us to require a password attribute in order to create a Dj object. Here I also set up the validations for both the Dj and Playlist class that prevent bad data from entering the database.

With the help of methods from ActiveRecord, and I ran my migration files by using the Rack gem(rake db:migrate) and established the relationship between the database and my models.

Setting Up Routes and Controllers

In order to apply the concept of separation of concerns, I created four controllers:

a central application controller where all other controllers inherit from, a djs controller for handling the creating of new Dj objects, a sessions controller responsible for logging in and and out, and a playlists controller, responsible for the full CRUD of Playlist objects. These routes render different erb files located in our views, which present the user with readable information or forms to create, update and/or delete objects. They are used by stating their use in the config.ru file.

• Create: For the create methods, I use ActiveRecord methods to collect the data provided by a user, in this case a Dj, via a form through a GET route and create an instance of an object which is stored in the database through the POST route. I use the same logic for both Dj and Playlist objects. If the information is not valid, a flash message appears and tells the user that it is not valid. This is thanks to the validations we set up in our models.
• Read: For the Read methods, I used another GET route and within this route, I locate specific object, either a dj or playlist through methods inherited from ActiveRecord and then display the information to the user in another Erb file set up in our Views.
• Update: The update method was the most complicated to get working but it is similar to the process of creating a new object. In this case the form is used to update an object’s attributes through ActiveRecord’s update method. In order for this to work we must add use Rack::MethodOverride to our config.ru file. The conditional logic prevents a dj from editing a playlist that was not created by them.

The conditional logic in the patch request prevents a dj from updating the playlist with invalid information. If they enter information that is invalid they will receive an error message.

Delete: the Delete method was similar to the patch method, except instead of updating an instance, it is destroys it once it is located. The delete button is only accessible to a Dj if they were the creators of that playlist.

Views

The files in the views folder is what is ultimately rendered to the users. This is the information that is displayed once a certain route is visited. This is where forms are also created. I had different views for the homepage, signing up, login in, creating a new playlist and a layout page that was yielded on every single route. Inside the layout erb page I set up logic so different things would be displayed across the application depending on whether or not one was signed in.

With erb forms, one can displau both Ruby code and HTML. The instance variables that are displyed on the brower are created in our routes. For example:

‘/djs’ route and djs/index file

There were many erb files. Feel free to check them out at them out inside of the repository.

Styling

For styling, I wanted recreate the feel that 90’s websites had. I played around with the stylesheet and also created a fake logo with the platform Canva.

Feel free to check out my full repo.

Thank you for your time.