Commando Theater CLI.
- Access a Sqlite3 Database using ActiveRecord.
- Have a minimum of three models.
- Build out a CLI to give your user full CRUD ability for at least one of your resources. For example, build out a command line To-Do list. A user should be able to create a new to-do, see all todos, update a todo item, and delete a todo. Todos can be grouped into categories, so that a to-do has many categories and categories have many to-dos.
- Use OO design patterns. Have separate classes for your models and CLI interface.
This program was made using ruby 2.6.1 with VS Code and having a small Gemfile which is here.
I will start by explaining project creation, file structure and with what gives me the ability to access my sqlite database using ActiveRecord. If you are making a CLI make sure you have these gems “gem ‘sinatra-activerecord’” and “gem ‘sqlite3’” in your Gemfile and running the command, “bundle install”. Sqlite3 gives us the ability to implement a database while Sinatra and ActiveRecord establishes our connection to the databases and give us the framework to understand and shape the data we pull.
Our database needs to be populated with tables and our tables need their respective models in ruby to access the way data and shape how we extract information. Our database tables define what we require for each instance of that class. The tables define our instances and the models define our relationships or associations between each model. Populating a database consists of, creating a migration, populating migration, migrating to the database.
Create a migration with ‘rake db:create_migration name_of_migration’. Naming convention states that the name should reflect what the intended action of the migration is. If it is to create a table simply call it the name the table. If it is to modify a table call it the modification action.
This creates a migration in your db folder and allows you to define the migration. We can see that our migration class has been created, is inheriting from ActiveRecord, using the Migration module, and has a method defined with a closing end statement. Here I use the create_table inside of my change method to define my class’ table and parameters for creation in each column.
After we have our database staged properly with the correct change methods for each table we can run ‘rake db:migrate” in order to migrate our changes to the database.
Running these migrations create our tables and add to our schema.rb file which shows how are database is structured. The columns created for these tables are values necessary to create an instance of that model, our arguments, or parameters. One more thing,
Each table needs its respective ruby class. Here you define the relationship between the data and models that allow you to call on belonged data using methods in your class. These defined relationships are called associations. Ruby class naming conventions have these classes singular and lowercase.
The models necessary were guest.rb, ticket.rb, movie.rb. There are more classes that I used in the final version of the project(≤==link to final version). The associations would be that a guest has_many :tickets and has_many :movies through: :tickets, a movie has_many :tickets and has_many :guests through: : tickets, and a ticket belongs_to :guest as well as belongs_to :movie through: :guest.
It is our joiner class in our many to many relationship. The associations we set forth assign this ticket to our guest and a movie. This means that I am able to write methods that allow a guest to call on their tickets as well as a movie.
Associations are what allow us to relate models to one another in a database, and to assign instances of one model to another using primary-key foreign-key relationships. An instance is given a primary-key that becomes a foreign-key when being assigned to another model.
We gave guests the ability to “Sign Up” which created(CREATE) an instance of the Guest class and saved it to the database with a specific id. We would have the guest input a name and a password for the parameters of our .create method that are present in our schema.rb file, would allow a returning user the ability to use those credentials to “Sign In”.
Revisiting and using “Sign In”, guests are able to view, or READ, their account information and any parameters we set forth when we had them create an instance of the guest class. Since we have made our associations in our models, each guest has the ability to view their tickets as well as movies they have through: : tickets.
I decided to make this application interactive by including an action a user would have to take in order to continue on. I called this method continue and would call on it at the end of other methods. It looked like this(thank you, Nestor). At the end of each function the user would be prompted to continue, which would lead to the next called function.
Once in the program a guest would be able to search movies from our database. I wanted the guest to not only be able to search through a list of movies but have a way to filter so I included search by genre.
In order for a guest to see a list of the movies first I had to make movies accessible in that function by assigning the list of movies to a variable, “movies”. I then prompted a guest to select how they wanted to search and based the return on their choice.
When a guest decides to purchase a ticket I would then use their movie selection choice to create a ticket, which was our joiner class. Making this a global object allowed me to call on their ticket in other functions and classes in order to remind or display them later on. Global variables use a “$” in front.
With all of my functions made in their respective files; one file was for main menu functions, one for narrative, and classes with thier associations, I then called on these functions in my program.rb file.
Because the program.rb file is requiring my environment file, which is requiring all my apps, I am able to call on functions I made in separate files and run them from program.rb. These functions will run in order and is a snapshot of the flow of my application. With our continue prompt set up we give the guest the ability to say when they are ready to continue, adding another layer to user interaction.
There is some insight to the workings of my first CLI application. Hope you enjoyed and come back for future builds and projects. Talk soon!
