Sinatra “You will know this Ditty!”
This blog is to not only help myself articulate the flow of Sinatra and help my understanding of it, but to also maybe help anyone who comes across my blog looking for answers.
Step 1.
First we want to install the ‘corneal’ gem to our ruby. In our console we will type gem install corneal . The corneal gem helps with file structure within Sinatra!
step 2.
Lets make a Sinatra Project! In our console lets type corneal new APP-NAME once our project has finished loading, we can open our project and take a look at all the goodies corneal has provided us!
step 3.
Once we have our project open we can start by making sure all the gems we want to use are laid out within our gemfile. In the project that I created I am using an API. I added two extra gems to the file ‘rest-client’ and ‘json’.
Once we have our gems we can run ‘bundle install’ in our terminal!
step 4.
After installing our gems we can start by adding tables to our database. This is a good starting point for our project. We need tables for our database that way when we make our objects in our models folder(we will get to this later) they can have attributes. We will be able to use these as attr_accessors by inheriting ‘ActiveRecord::Migration’ to our tables. The database we are using is called Sqlite3. We can access the tables, schema, and data within sqlite3, but that’s for another blog. When making tables in our database we must specify whether or not the attribute/column is a string, text, integer, date, etc. We can also name the attributes/columns what ever we desire, preferably something that relates to our objects we will be creating in our models. After we have our tables set up we can migrate using our Rake gem. If you type in your terminal ‘rake db: migrate’ your tables will then be migrated within the sqlite3 database. After we have our schema set up we can now move on to making our models.
Step 5.
Making models are fairly simple enough. Models help us create objects to be stored into our database. We also inherit ActiveRecord into our models as well. That way our database and models can communicate with each other. We will also need to set up our relationships between our models. We can determine our relationships by looking at it as a hierarchy. We determine relationships by using ‘has many’,’has_many_through’, ’belongs_to’ relationships. Sometimes we use a ‘many_to_many’ relationship which in this case involves making another table in our database giving the foreign ids of two tables to that new table. You can see an example of this in the picture above. We also make a model for our new table as well, which you can see below. The ‘many_to_many’ relationship is not always needed only when two objects have many of each other existing on both sides. Once we have our relationships set up we can move on to setting up our controllers.
Step 6.
Controllers consist of 4 different requests GET,POST,PATCH,DELETE. A user will send a GET request to the server the server will communicate with our controller to render the page. Sometimes GET requests will render a form, example is a user sign up page. After filling out a form the form will have method of POST. Once the user submits the form it will send a post request to our controller through the server. The POST within our controller will make a new user using the parameters the user passed in on the form. once a new user has been created the POST request should redirect us too another GET request. Now let’s say we need to edit our user. Well we can render another form through a GET, however there will be a slight difference to this form we will have to use ‘MethodOverrride’ gem. We use this within our ‘config.ru’ file. Make sure when configuring this within the config file we place it above all of our controllers or PATCH and DELETE requests will not work. Back to our form we will need to add a hidden input below the form tag. We will call the MethodOverride through the name attribute simply like this ‘name=”method_”’ you will then set then set the value attribute to ‘value=”PATCH”’ This will over ride our POST request with a PATCH. Once submitted we can now update our object within our PATCH request located in the controller. We can also use MethodOverride to DELETE an object as well. We would basically use it the same way we did with PATCH, but we could replace all our inputs with a just a button to send our DELETE request.
Conclusion.
We can simplify all of this into what we call CRUD. CREATE.RENDER.UPDATE.DELETE.
This is the flow of Sinatra! Our user communicates with the server, the server communicates with the controller, the controller communicates with the model, and the controller sends a view through the server back to the user to be rendered on the browser! For the basics of Sinatra that basically covers it. Of course there are validations, sessions, helpers, and etc. that help with the our Sinatra application, but again that’s for another blog. I hope this helps with understanding the flow and setup of Sinatra!
