Module 2: Building a CRM website and using Corneal

Well hello. We made it far. Reeeeal far.

I just completed my app with everything I’ve learned so far. It felt like building a website from scratch; which I did, just without the web-server hosting part. I used the Sinatra framework with Active Record, following the MVC model, with multiple models with has_many, belongs_to, has_and_belongs_to_many, and has_many :through relationships. I needed to create a user with an account that validates the log in, stores session information, and have the user be able to utilize CRUD resources.

Here’s what I did:

My app uses a database that stores and creates information of two different types of users: DJs, and promoters.

The DJs are able to create and log into their account, view gigs that they have coming up, edit their personal information- which can be their names, bios, genres they play, and even are able to delete their accounts. The DJs are able to select and de-select genres that they play or are associated with, and even create new ones.

The promoters are essentially able to do the same thing- log in, view and edit their info, delete their accounts. However, the difference here is that only promoters are able to create events, and add DJs to the these events, or “Gigs.” The promoters are then able to also delete and edit [only]their own gigs.

There is a page that displays all the upcoming gigs that can be viewed even if you’re not logged in, contrary to everything else on the site where you need access to a log in.

Using Corneal was my saving grace. Corneal is a gem that provides you with an MVC skeleton that’s pre-populated with data and code the program will assume you need/use. You can always edit that out later.

Below is what the MVC file structure looks like, which is all taken care of/created by Corneal.

└─app
  ├── controllers
  │   ├──application_controller.rb
  │   └──new_model_controller.rb
  ├── models
  │   └──new_model.rb
  └── views
      ├──new_models
      │  ├──index.erb
      │  ├──show.erb
      │  ├──new.erb
      │  └──edit.erb
      ├── layout.erb
      └── welcome.erb

It was nice to have a template of CSS to start off with. However an issue that I ran into was that every time I tried to update my CSS page to new code, it wouldn’t update until I logged off my computer for a while (like the next day). A way around that is to create an entirely new CSS page to link to your app.

That was a bummer to try to get around; there’s no reports of bugs regarding the lag in updating the CSS sheet. Corneal is however, said to need updates and isn’t kept hip with current updates.

Click here to view the documentation on this gem.

Some obstacles I ran into and stumped me at first:

Aside from the CSS page being slow to update, here are some things I ran into…

• Since I have 2 different types of users on my site, that means I’d need to have double the join tables for persisting and saving my data to store foreign keys. That meant having a lot of data migrations because I’d forget when certain associations needed a join table, and I got a little carried away by wanting to add more data to my models.
• Two users also meant needing to have two different session ids to store log in data. At first, I didn’t realize that was necessary until I logged into my DJ user, didn’t log out, and then went to try to log into my Promoter page but was redirected to the promoter show page with the same ID as the DJ I logged into originally. That was fixed by changing the name of my session keys on both classes, and automatically logging out of a user when a certain user class tries to log in to a different user class.

• I didn’t realize how important the difference between have a has_many and a has_and_belongs_to_many relationship was. I ran into this issue when I tried to add a DJ to two different gigs, and each time I saved the DJ to a gig, the new gig would overwrite the other gig it was a part of. It took me….3 hours to figure out what was going on LOL. At first I thought it was an issue with my code in my controller. Then after testing it out in my debuggers ( tux and pry), I decided to look at my models again to see if they were even given a relationship. I saw that the DJ class had a has_many relationship to a gig, which would make sense- a DJ would have many gigs. However, thinking about the logic of my program, the Gigs I created would have many DJs yes, but it would also mean that the DJs not only had a lot of gigs, but they would also need belong to that Gig, hence the DJ having the has_and_belongs_to_many relationship. And Viola- that bug was fixed.

There are so many different functions that I can keep building into this app- I feel like it’s endless. I was surprised and really enjoyed how easy it was to use bcryptto encrypt my passwords.

Some thoughts of what I can add in the future:

• An about the party [bio] column to the Gigs table, where it’s an explanation of what the gig can be.
• A public display page that shows all the DJs in the database
• A private Gig that only the DJs and promoters involved in it can view- so it won’t be displayed on the main page.
• A search function
• Contact page