Routes, Views & Verbs: Understanding the flow of Application Controllers & HTML Views
Oof it’s been a journey in this second phase of Flatiron, but I’m glad to finally be coming out on the other end a lot stronger coder! This phase required that we build an MVC (Models Views Controllers) Sinatra web application using ActiveRecord. One thing I really struggled with all throughout this phase of the program was knowing where I was in the program, especially once we were strictly browser bound with our projects. Before that, we were in the safety of test suites and our local terminal that allowed us to “pry” our way into each and every detail along the way. As we entered into our project, I clumsily began trying to navigate my way between the browser and the terminal. Enter: paths and views…
The “path” or “route”, similar to many other of its namesake, basically gets you to the view and takes you from the view, in manner of speaking. A walk through most application controllers should render at least the following basic html “views” (or in the case of delete, an html form inside of the edit view) in this order: index, new, show, edit, delete using a combination of the following methods: get, post, patch, delete. These methods/verbs are associated, respectively, with each of the CRUD verbs: create, read, update, destroy, which fortunately are pretty self-explanatory! In order to render a view to simply view or read it, we use a get method. This method allows us to read the page, to see it, but nothing else!
Written like this:
This is the most basic form of a get method, it uses the root path '/' and renders the index view and for the most part looks very similar to any other Ruby method syntax — we’re passing the get method an argument of the root path, ('/') , then we are telling the browser to render us that view: erb :"/index". This root path get method usually lives in the application controller, from where the program is directed to run through the config.ru file. This seems super simple, but trust me, when you’re first exposed, it can get pretty confusing.
The user get-s this index view simply by going to the root view '/' in their browser, ie www.medium.com/. From there they will have several options to continue their browsing pleasure. From the back end side of things, the next step is typically to run through the rest of the controller, adding all of the “verb” methods in order to interact with the html views. In an application where the user is navigating to different pages, we need other index pages that give general index information, a user home page essentially. After we get the root path, we get the index for the '/users' path which is found at erb :"/users/index":
This will render the User Controller’s index view. From the index view, the user will likely need the option of logging in or signing up for an account. This is where the back and forth can start to get a little tricky to follow. We are going to need get methods to “read”, or view, a page and fill in a form and from there we will need to post, aka make a request to the server to “create” or “post” a change, in this case add a new account to the database. We get the signup form with erb :"/users/signup", which will render the signup form view, often called new.erb, but in this case we’ve called it signup to make it clear that it is not just creating new data for an account, but creating a whole new account. From here, the user fills in the form and “submits” it back to the server to post the change and send the user to their new account homepage, aka show.erb, a view we now associate with the user’s id, like so:
The last method shown above, get '/users/:id' is simply the final step after we post the new data and create the new account, we need to render the information to the user through the “read” method of get. So again, we look at a view, then if there’s a form, we fill in information to send it away and “post” the new data, then we read what we posted and go from there.
Of course, you might already have an account, in which case…
Basically the same thing, but we’re allowing the user to input their already saved account information and render their account.
Lastly, we have to let them logout because it’s only fair! Here, the user really just has to click a button and it’s a done deal, we use session.clear to clear the browser session’s cookies and byebye, baby! We no longer are keeping track of that user’s experience for this user session.
Hey, wait! You said there should be “patch” and “delete” methods. Ok ok, you’re right, this example is lacking in those methods, which are both really important. When we’re working with multiple controllers, there will not always be the same needs. In the application referenced, I did not need those methods in the User Controller, but I did need them in my other two controllers: Product and Category. Here’s what the get and patch methods look like:
So we’re get-ting our erb :"categories/edit” view, aka edit.erb file. We’re rendering a form for the user to fill out and then we are using the patch method to request an “update” from the server upon which we grab that newly entered information and render it for the user to view in the show.erb view, so they can confirm that the edits were made.
Then we give them an embedded delete form inside of their show.erb file using the '/categories/:id' path and allow the user to click the delete button to say “adios” forever to whatever sad item they deleted.
Now we just have to figure out how to get those darn HTML views working…guess we’ll save that for next time!