It’s Infrastructure Week at the Flatiron School!

Photo by Martin Sanchez on Unsplash

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!

Images from The Wizard of Oz © Warner Home Video 1939 — gif .created by yours truly

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:

  1. The client (aka your browser) sends a request to a remote server: i.e., via a human person typing google.com;

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.

In the terminal, you can call .class and .method on any Ruby object to see what tools are available for the object, depending on its class.

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.”

Yep, I still dig pizza. Inserting self-referential link here.
ApplicationController inherits from the powerful ActionController::Base

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: require and 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!

There is definitely a wizard over at Rails. His name is probably Matz!

More from Journal

There are many Black creators doing incredible work in Tech. This collection of resources shines a light on some of us:

Ex-professional actor, reinventing myself, living the life in NYC. Recently graduated from Flatiron School’s software engineering bootcamp program.