Green Light — The Rails Edition
As we progressed through our Rails unit, I often found myself thinking “this is just like better/easier/more efficient Sinatra.” We were constantly learning new techniques that I wish I had known while building my Sinatra project — an application called Green Light that allowed users to keep track of their feedback on scripts that they had read. So when it came time to start my Rails project, it only made sense to take that idea and adapt it.
Since I didn’t want to do the exact same project twice, the functionality of the Rails edition of Green Light differs slightly from the Sinatra Version. Instead of keeping track of an individual user’s script coverage, this project is designed for teams to keep a running list of scripts and their formats (ie, half-hour comedy pilots, feature films, etc.) together. Utilizing CRUD, nested forms, and nested routes throughout the project, users are able to add, edit, and delete scripts — each of which is associated with a format. Users can also add formats as well as add scripts to a particular format. If you want to see a walkthrough of the application, scroll to the bottom. If you want to read about the behind the scenes, read on!
Models, Databases, and Associations
When it came to setting up my models and database, I knew I wanted to focus on scripts, formats, and users. Unfortunately, I learned the hard way that the word “format” has its own functionality and Rails would try to read it as something other than my model when using it, so I had to rename it as “department” and change it in my routes using resources :departments, :path => ‘formats’ so that my URLs would read in a way that made sense to users. Within these models, I also included validations to ensure that no forms could be completed without the necessary information. For example, I required the presence and uniqueness of both a script’s title and a format’s name.
One of the most important parts of our Rails unit — and this project — was learning more about associations between models. I set my models up to look like the following:
User
has_many :scripts
has_many :departments, through: :scriptsScript
belongs_to :department
belongs_to :userDepartment
has_many :scripts
has_many :users, through :scripts
In plain English, this essentially means that a script belongs to both a user and department (format), and users and departments are joined together through their associations with scripts. Because they are joined together through scripts, I included a foreign key for both users and departments within the script table, as seen in this excerpt from my schema below:
create_table "scripts", force: :cascade do |t|t.string "title"t.string "logline"t.datetime "created_at", precision: 6, null: falset.datetime "updated_at", precision: 6, null: falset.integer "department_id", null: falset.integer "user_id", null: falset.index ["department_id"], name: "index_scripts_on_department_id"t.index ["user_id"], name: "index_scripts_on_user_id"endadd_foreign_key "scripts", "departments"add_foreign_key "scripts", "users"
Associating these models allowed me to do things such as create forms that would include both the script and format models and tie the two together, display a particular script’s format, and display a list of all scripts that belong to a format.
Devise and OmniAuth
While in my previous version of Green Light users had the ability to sign in, sign up, and log out of accounts, we learned about a few gems in this unit that I wanted to implement to make the process more efficient and robust. The first of which is Devise. Using Devise, I was able to simply run a few lines in my terminal and it set up my user model, database, and views for me. It made creating a seamless sign in process so easy!
Another gem we learned about was OmniAuth. OmniAuth allows a user to log in with a third party such as Facebook, Google, Github, etc. While I had to do some digging to figure out how to implement it with Devise, it was fairly simple once I found a good tutorial. The key parts of using OmniAuth are to be sure that you install both the OmniAuth gem and the gem for OmniAuth with your chosen provider (I used Facebook, so I used the omniauth-facebook gem), updating your User table to include OmniAuth, and making a few tweaks to your other files where necessary.
Implementing Devise and OmniAuth made a huge difference — the login process feels so much more professional than it would have had I done it without them.
Formatting and Styles
Another difference between the Rails and Sinatra versions of Green Light is that I opted to not use Materialize CSS this time. While Materialize was easy and looked great, there were a lot of small details I wanted to customize in a way that was not particularly easy with Materialize. I also found that Materialize doesn’t play nice with collection_select, which creates a dropdown selection in forms. Since allowing a user to select a format from a dropdown list is a huge part of my functionality, this didn’t seem like a good option. I decided to create my own stylesheet instead. With this, I was able to get the exact coloring I wanted, change the fonts, and change details in sizing wherever it felt necessary without worrying about a template accidentally hiding something.
Walk Through — Green Light in Action
When a user navigates to the homepage for the first time, they will see the following page:
You’ll notice the navigation only allows us links to sign in or sign up — which means we need to either create an account or sign in! Depending on which route you take, you’ll see one of the following pages:
These pages were provided when we implemented Devise, as mentioned above. They both include a link to sign in using Facebook, which utilizes OmniAuth. If we tried to access any page we shouldn’t have access to while not signed in, we would be redirected to the log in page. However, once we sign, we will be redirected back to the homepage with a new navbar — this time with links to a list of scripts, formats, options to add each, and to sign out. Let’s see what it looks like when we click “Scripts” in the navbar to navigate to our list of scripts:
Here, we are given a list of all scripts in a table with their title, logline, and format. We have two options for navigation within this page — each title is clickable and brings us to a page specific to that script, and there is a button to add a script at the bottom. Let’s start by adding a script:
Here we are given a blank form where we are able to add a new script, logline, and associate it with a format. The dropdown list includes any format that has been created by the user. If you don’t enter a required field, such as the title or format, you will get an error and the entry will not save. If the form is filled out with no errors, it will save and you will be redirected back to the list of scripts — which will now include your most recent entry:
Next, let’s see what happens when we click on the link to a particular script from the script list, using Parks and Recreation as our example.
We’re given all of the user-submitted information for this particular script, as well as the option to edit or delete it. If we edit it, we are brought to a separate edit page that is pre-populated with our previously entered information. Let’s say we want to change “Parks and Recreation” to “Parks & Recreation”. We could edit that in the field and the change would show in our script list as well as the Parks & Rec page.
Now that we’ve seen how the scripts are created, viewed, and changed, let’s take a look at our formats. Since our formats don’t need more information than just a name, our list looks a bit more simple than that of our scripts:
Similarly to scripts, we can click on the link and be brought to a detail page for that particular format. In this case, it is simply the format’s name, a link to see a full list of all scripts of that format, and a button to add a new script to that format.
When we view our list of scripts for the format we receive a list of every user-submitted script associated with that format, like so:
Now, let’s try adding a new format. We’re given a simple form to add a format name.
Once submitted, the new format will show up in the list and as its own page.
You’ll notice that on each format’s page there is a button to add a script. This actually brings us to a form to add a script to this particular format instead of the general new script form we saw before. When we add it here, we will automatically be redirected back to our scripts page, where we will see it added to the list with the appropriate format!
With Green Light, readers can add scripts as they come in and delete them when they have read them and want to remove them from their reading list. They can also easily keep track of what kind of scripts they have on their plate. If a reader knows they only have time to read a short film script right now, they can use Green Light to see a list of outstanding scripts.
