My last blog post, I went over the basic structure of every web application which includes the model, view, and controller. Recently, my software bootcamp Flatiron School, transitioned into the second part of our curriculum where we're learning about Ruby on Rails. For the first week, Ruby on Rails was extremely frustrating. Programming already had so many rules in order to construct the logic for algorithms, but Rails now wanted us to organize the logic, to the point of naming variables. At first this felt like an overbearing teacher that wanted the right answers AND neat handwriting on a test. Ultimately, i was able to get used to the notations and appreciate how RAILS neatly operates all levels of MVC to set up CRUD functionality.
As previously mentioned, Ruby on Rails is a web framework. An official definition of a web framework is a software framework that is designed to support the development of web applications including web services, web resources, and web APIs. Rails is very opinionated and follows convention, but the reason for this is so that the logic to building your website can be organized. The advantage to this is that setup very easy and only requires a couple of commands on your console.
Before we jump in let's first begin with installing the gem onto our computer. To do that first run gem install rails to get the Rails gem installed onto your computer.
Now you have Rails available, we can really start taking advantage of the Rails. First we can get started by setting up our basic environment, which we can set up with the command: rails new (name of new project)
With that one line of code, you'll get this entire setup.
Pretty neat!
Now that we have that going, we need to work with a special file on Rails before we get to anything that has to do with the MVC or CRUD functionality working on our web application. This is our routes file.
In the MVC model, we have the model which mediated by a controller to determine how the view is manipulated. In this case, what we have is a file that recognizes the URL that our user accesses and then links them to certain controller actions that we define in our controller file.
Here I have displayed for us two different ways you can write your routes. The first one is the explicit form which is written as:
get '/posts/:id', to: 'posts#show'
There are essentially three parts to this code that tell us what it's trying to do. 1) We have the HTTP verb which in this case is 'get'. The HTTP verb correlates with what CRUD action we are trying to perform, 2) the URL itself that is being linked to, 3) the controller action that that contains the logic for the action.
Our second line has our implicit form for routes:
resources :posts
Ruby on Rails being the smart framework that it is, is built with the understanding of the 7 restful routes. This is essentially an ideal architectural style for building out HTTP routes in connection to CRUD methods. If we type rails routes in our console, it will give us all the routes that we currently have access to (including the explicit route we wrote earlier).
As you can see, it once again gives us the HTTP verb (covering all 4 CRUD routes w/ get, patch, post, delete) along with the corresponding controller action and URL. You'll also notice the underscored variables that end with 'path'. These are used to easily redirect to any of our controller actions within the controller or even the view.
Now let's take a look at our controller file.
There's a lot here, so before we dive into it, there's a couple things that Rails is already doing for us that makes it easier to understand. First off, Rails actually looks for a view folder with the same model name as our controller and corresponds every function in our controller file to a view file in that folder. So for example, our first example index in our 'PostsController', would correspond to a html/erb file named 'index.html.erb' inside the 'post' folder in our views folder. Since the view involves a much larger topic regarding organizing HTML and data received from the controller, I'll just explore the logic behind the middleman controller. Let's just go ahead and go over everything in order.
First off we have the index function that we just mentioned in our previous example. First we define an instance variable from our model data, which we'll be able to use on the index page which is linked to this page. For this page, we've called the Post.all function to refer to all instances of the post model in our data to display on our main page.
Next we have the new and create functions which are related to each other. The first is simply a get function which refers the user to the 'new' page that has a form, which a user can use to submit information. This form has a post method which is what refers to our 'create' function. Just for reference this is what a typical text input form would look like. This one in particular what we call a form_for form.
The create function is then a post method that takes the information from our 'new' page form which is defined here as 'post_params' and then passed into our 'Post.new' function which will create a new instance of our model. This particular function takes the new instance variable and checks it for validity before it saves it into our database. If it isn't valid, it will return us to the new form page and display an error message.
The create redirects us to the page for our newly created instance variable. When we created the instance variable, it isn't explicitly stated, but it is created with an id number that gives us reference to each unique instance. The next function "show" will pull up the instance variable based on the id given.
The next two functions 'edit' and 'update' function work with the same function we require for our show page, and selects the instance variable we are looking for based on the id of the instance. Once we have set the instance variable, we use the 'assign_attributes' function in order to set the variables to what was given in the post, and then we save if we have a valid input.
One way we could have done both the create and update function is to use the corresponding 'create' and 'update' functions in order to receive form information and to save that information at the same time. However, in order to use our validations, we used 'new' and 'assign_attributes' in order to separate these interests into two separate functions and validate before we move on to the save function.
The last is the delete function, which selects the instance we are working with based on the id and then uses the destroy function on it. On the view page, there will be a delete button which is basically a form with post with hidden attributes that links us to the route of the delete controller action.
There's a lot more that you can do with views and models which I didn't talk about in this article, but for now this explains the basic backbone which gives our web page CRUD functionality through Rails. With this understanding, what was a really crappy experience with all of its pre-set variables and methods, Rails has become a really useful tool which I will continue to use to do web development.
Top comments (0)