It’s Infrastructure Week at the Flatiron School!
Welcome to vicarious Flatiron School, Mod 2!! While learning the Ruby programming language in Mod 1 we interacted with our application Models in the CLI (Command Line Interface). I kept wondering if we were in Rails and somehow didn’t know it. “What is this wondrous Rails I keep hearing about??” Way back then (aka, two and a half weeks ago), our Ruby apps looked somewhat like the most primitive version of Space Invaders, and now on Rails, projects are beginning to look like an actual, albeit fairly basic, webpage. Baby steps!
At its essence, Rails is a framework that utilizes the Ruby language with a bunch of cool new tools (plus Ruby’s awesome Active Record database interface) to bring our information to a webpage, using a fairly standardized file structure. (I recommend a good/quick breakdown on creating a new Rails app here, written by a cohort-mate here at Flatiron).
In order to get past the basics of Rails and its MVC (Model/View/Controller) software design pattern, we’ll want a quick refresher on the client-server response cycle:
- The client (aka your browser) sends a request to a remote server: i.e., via a human person typing
- The remote server (aka a server over at Google) receives the request, considers the HTTP verb (a great/brief read about HTTP verbs can be found here) and route/path (url), using this information to pass to the appropriate Controller;
- The Controller takes this information plus the method/action called, “chats” with one or more Models who “chat/s” with their database, and some info gets relayed back to the Controller;
- From here the Controller sends the retrieved data over to an .html.erb View (template) page which corresponds to the action/method called by the router, which is then rendered across the interwebs…
- …to the client (browser) who translates this information onto your computer.
Want to read this story later? Save it in Journal.
Whew! I know. That’s a lot right there. One could spend an hour (or seven!) just on the intricacies of the client-server response cycle. But we aren’t going to do that. We are going straight to Controllers. As per the Ruby on Rails Guide: “A controller is a Ruby class which inherits from
ApplicationController and has methods just like any other class. When your application receives a request, the routing will determine which controller and action to run, then Rails creates an instance of that controller and runs the method with the same name as the action.”
So a Controller is a class which contains methods. It is an essential coordinator in the above mentioned client-server response cycle. But what is Application Controller, you may ask? ApplicationController is a Controller class in Rails, which inherits from ActionController::Base.
Remember: “By default, only the ApplicationController in a Rails application inherits from
ActionController::Base. All other controllers inherit from ApplicationController. This gives you one class to configure things such as request forgery protection and filtering of sensitive request parameters.”
The ApplicationController is in some ways the gatekeeper to all the other Controllers. You can actually write any rule/condition in your ApplicationController, and this condition will apply to all other Controllers within your application. And just like any class will do, when called upon it instantiates a new Application instance.
What is ActionController::Base? Well, going back to the Ruby Guides:
“Action Controller is the C in MVC. After the router has determined which controller to use for a request, the controller is responsible for making sense of the request, and producing the appropriate output. Luckily, Action Controller does most of the groundwork for you and uses smart conventions to make this as straightforward as possible.”
:: is just the conventional symbol for NameSpace. The geeks at GeeksforGeeks tell us: “A namespace is a container for multiple items which includes classes, constants, other modules, and more…. generally, they are structured in a hierarchical format so, that names can be reused…. the namespace in Ruby is defined by prefixing the keyword module in front of the namespace name.”
So the point of the :: symbol is to tell us that ActionController will “contain” Base and its functions in a hierarchical-type format. There are other options besides Base. For instance, ActionController can be namespaced to Metal, which creates a more limited functionality for your Controller. Or ActionController:: Parameters, which “allows you to choose which attributes should be permitted for mass updating and thus prevent accidentally exposing that which shouldn’t be exposed. Provides two methods for this purpose:
permit.” (sound familiar? *cough_strong_params_cough*) For a full list of all ActionController options, feel free to browse here.
If we call .class on ActionController we will see that ActionController is a Module! But if we call .class on ActionController::Base we see that it is a Class. (This aspect of the topic will require much more education on my part. I’ll double back with you after I’ve received a PhD in Ruby!)
The best short answer I can provide at this point is that ActionController::Base provides the standard toolkit/sprinkling of Ruby functionality/magic that we have come to know and love. And for now, that is good enough for me!
More from Journal
There are many Black creators doing incredible work in Tech. This collection of resources shines a light on some of us: