So as I mentioned in the last part of rendered, we built a fairly simple rendering engine using Rails’ built-in templating engine ERB. And that’s fine, but there’s still a lot of code in our controllers and Rails has a full featured rendering system called ActionView, which not only includes the rendering methods but tons of helpers to build pre-filled forms, etc.

So first let’s add ActionView to our Gemfile:

And after a bundle install, ActionView is available. It also adds the “erubis” gem, which is better, safer, and faster ERB handling than the simple built-in ERB handler.

We’re also going to add the railtie to our application.rb just so that ActionView has access to the various Rails configuration files:

And lastly, add the renderer to our controller:

In a Metal, you need to define where the views are location, such the line in #18. But notice that we got rid of all that rendering code. And our pages now render!

Going over all the different helpers would take far too long, so I’m just going to mention them as I get into them. The Guide on Form Helpers is a better resource. However, there is a couple of big notes to add:

First, HTML safety. Nasty insertable HTML and Javascript to steal your cookies and delete your pages is everywhere, so we don’t want to trust anything from the database. So every String that passes through ActionView is sanitized unless it’s marked as safe. So for example, if we change our @hi variable to @hi = '


sup

', then what gets outputted in our index is: Front Page! <h1>sup</h1> It actually will convert so that it displays the HTML. This is a safety first option, but if for some reason you can trust the output, then you can use #.html_safe in the ERB to mark as safe:

This marks it as safe to straight output vs. sanitizing.

And secondly, layouts! Should be obviously useful as any webpage has the same headers and footers, so let’s render the inside from the outside. To enable, just change to ActionView::Layouts:

And you’re good to go. While you can use the ActionController#layout method to define custom layouts, by default it uses the name of the controller to use as a layout. (If a layout doesn’t exist, then it will just render straight pages.) You put layouts in the app/views/layouts folder, separate from the controller views.

So let’s make a really simple layout:

And that’s it! With the magic filename, you have included a layout. Note that for layouts to render their insides, you must include a yield, which returns the inside of the layout.

Just to finalize things up, we’re going to set the controller to ActionController::Base now:

ActionController::Base is nothing but the Metal, but with all the batteries included. So it includes ALL the modules (and more!) that we’ve mentioned, preloads the view paths, and all that good stuff.

And just as a small detail, most Rails apps don’t have their controllers from the Base, but include an ApplicationController and use a hierarchical format:

Because of hierarchy, this allows the filters to act for all inherited controllers, and is typically a good idea to have all controllers inherit from this.

And that’s ActionController. We have now built a very, very fancy method of generating webpages, but there’s no meat here. We’ll be going over the basics of the form generation soon, but to do that, we need something to save against, so we’ll be working next on persistence.

If you want to get ahead in the next few lessons, read up on the basics of SQL commands. (We’ll eventually be using Postgres for this project.) However, unlike HTML where you need to know the basic tags and such, you technically don’t need to know anything about SQL since Rails/ActiveRecord completely abstracts it out. However, it’s good to know that the abstraction is just a fancy SQL generator, so knowing why it works gets a leg up.

As always, working code is available here: https://github.com/ROFISH/ruby_for_programmers/tree/master/15

And now for something completely different.

Let’s say you want to generate some HTML. Using interpolated strings is generally not a good idea as it can lead to unmaintainable code. The best way to handle this is through a templating engine, which is output text intermixed with code. Thankfully, Ruby itself contains it’s own built-in templating engine: ERB

‘binding’ is a special variable that is an object that contains the current variable scope. Yes, even scopes are objects that you can pass around. (Not recommended outside of template engines, as it messes with the garbage collector and may lead to memory leaks.)

There are three different tags to invoke:

The first allows one to write code before, and around, text. The second puts the result of code in the the output itself. The last is a way to write a comment. (You do write comments don’t you?)

So let’s add erb to our controller:

But that doesn’t really abstract that out enough to be useful. However, we can now put the text into different files, which is even better! We’re going to put the views into app/views/CONTROLLERNAME/ACTIONNAME.html.erb :

So as you can see in the controller, we’re pretty much doing the same thing, which means abstraction time and another new module: ActionController::ImplicitRender, which simply calls #render after the method is run:

And let’s add some more programmability with that:

This lets us pass some options and force a different type of render if we so please. In this case, it lets us give a specialized 404 error if the page id isn’t what we expect. You can render a text value and a status. But what if we wanted to render a different layout? Well all that, and more, is in the ActionView, a culmination of all the rendering points and more, in the next part.

As usual, working code examples are in my Github: https://github.com/ROFISH/ruby_for_programmers/tree/master/14

Earlier we had put together a basic controller and used the Routing and Metal to render some basic pages, but since we’re going to build a simple Generic Content Manager out of this, the parameters seem important. The method in which we got that information was out of a weird quirk of information that was automatically included in the env variable that was passed around. However, there’s better ways to get this.

This isn’t a module but just automatically included in Metal that I forgot in the last part. The params variable holds all the parameters that was sent to the page, including the GET parameters, POST parameters, and parameters set by the routing:

We’re also going to add Instrumentation to the controller too. This adds tons more useful logging like page benchmarks and displays all the parameters. We also need to make a small change to our application.rb file too:

This adds the ActionController ‘railtie’, which adds useful information to the class like where the Rails log is, ability to have a config information in the config/environments folder, and the like. Don’t forget to restart your app, and you’ll notice more logging information on each page load. Cool:

What page and how long it took and what parameters, all useful information.

Rescue lets you create custom rescuables in case something goes wrong:

Pretty simple, this detects a Ruby Exception (or a subclass of Exception) and lets you render a special page from a specially defined method. In this basic example, I divided by zero accidentally in my code and rescued from that error. I should note that this is controller-wide, mostly as a last-ditch failsafe to render a decent 500 or 404 error to a user rather than the built-in HTML files.

Redirecting just creates a simple #redirect_to function that creates all the HTTP parts necessary to redirect a browser to a different page. (For the SEOers in the crowd, by default it’s a 302 Found or temporary redirect, you can set it to 301 Moved Permanently or 303 Other if you so desire.)

UrlFor is a special class that helps you create URLs from your list of routes and the current route you are using. Note in the above it says :action=>:show, :id=>”butts”, (which I’m unsure why I used the older hash rocket style, but it’s a habit). In that case, it doesn’t define a controller so the UrlFor assumes that the controller is the one that I’m on. If you use redirect_to :id=>”butts2″ while in the #show action, then it’s the same as redirect_to :controller=>”mainpage”, :action=>”show”, :id=>”butts2″ since it will assume the same route elements for the ones that are missing. Very useful for dynamic URL making.

There’s a few more modules we could add, but it’s better to look at the code and read about it since those are more “as you need it”:

• HttpAuthentication: Allows you to set a HTTP user/password system managed by Rails (vs. being managed by the HTTP server or forwarder)
• DataStreaming: Allows you to send files to the browser, either hosted and read directly by the forwarder, sent directly to Rack as a large string, or create dynamically generated files to force the browser to download (such as CSV files).
• Streaming: A still-in-progress addition that allows one to render partials of a page. For example, render the top part with the CSS and Javascript, send that to the browser to chew on early, then render the rest of the page to send to the browser. Still requires lots of specialized support (ie. most middlewares and servers don’t support it), but pretty cool if it all fits together.
• ForceSSL: A simple helper that enforces page loads over SSL and redirects if not on SSL. Useful for password pages and such.
• Cookies: (actual documentation here), Simple cookie handling if for some reason you need tons of random cookies. (Note that we’ll be using Rail’s built-in session management to handle cookies for us, so you don’t explicitly need this. This is only if you want raw cookie access)
• ConditionalGet: This handles HTTP caching on the user’s browser side. For example, you can tell a browser to keep a copy on a user’s computer and not download, thus saving time and bandwidth.

That’s some of the magic functions and defaults available to a Controller. As you can see, these functions mostly just get and set various HTTP information for you. Next time, we’ll be rendering. No longer will the view data be in the in controller, we’ll put that into it’s own file with it’s own logic. Yay! (Also Session Management to store data in cookies.)

As usual, working code for this part is available here: https://github.com/ROFISH/ruby_for_programmers/tree/master/13

Earlier, we briefly went over the controller as a way to store the methods of routes, but there’s way more to it then returning a bunch of status codes and headers. So now we’re going to add another piece of the pie, the ActionController, which is actually three different classes in increasing complexity, the AbstractController, the Metal, and the ActionController.

The AbstractController::Base just contains a base set of functions and modules that help out. Normally one wouldn’t make an AbstractController::Base, but this is just for show. So here’s our AbstractController:

So that doesn’t look much different then before. We still have to make our own self.action method. But we now have access to a few cool built-ins, the most important of which is the callback:

What it does, is allows a function to operate before all functions. On both pages, @hi is set. This is useful for tons of things like session management, page view counts, etc.

But, we still have to do that goofy array, so let’s get rid of it… with Metal. \__/

The ActionController Metal the base class that simply does what we already do with the array format and the action handle, but adds some sprinkles to make it look better. It’s only 235 lines long and doesn’t include much fluff.

So here’s our totally Metal controller:

All the Metal really does is abstract out the env and the array, and also by default sets the content-type to ‘text/html’. Which is still a bonus because this controller is now starting to look good. It’s got some basic includes at the top, and just responds with basic text. At this point, all we did was abstract out the basics even more. Outside of including modules (like the Callback), the Metal is just a fancier version of our starting basic controller that’s not part of any class.

The Metal alone is perfectly serviceable, and some people prefer to use it. History lesson: the Rails Metal comes from the merge of Rails and Merb, where Merb was a from-the-ground-up system with plugins like I’m showing here.

Since we’re (mostly) done with abstracting out how to build a webpage, the next few segments will focus on the ‘batteries included’ part of Rails.

A couple of extra notes about callbacks, first you can limit the callback, or even skip the callback, to specific functions. Just add the array of the functions:

Skipping filters is useful for hierarchical class inheritance.

Also, when a callback returns with a response_body (or renders or redirects as we’ll see later), it skips the rest of the call stream. For example this:

Would always render “mystery callback” onto a page and never even run the #index or #show functions. This is another useful thing to be mindful of, and yet another powerful feature. For example, if you want to enforce a user login, then all you have to do is check if the user is logged in, and if not, redirect them to the login page. It will both not run the code they cannot use (since they are not logged in) and it will redirect them to a page where they can login. Useful!

So as we saw in the last part, having different pages might end up being a slight pain, so let’s add some routing. First we’re going to need the actionpack gem, so lets add that to our Gemfile:

Note that we’re going to be using the latest beta version because by the time this is done, the new version will be out. 😛

Run bundle install to install your new gem.

Woah, that’s a lot of dependencies! We’ll eventually get to them as needed. But for now, we’re just going to include the routing part.

The config.ru allows the use of Middleware, or something that’s run before your app. So if you wish to use a something that automates something before every page call, such as routing, then you can make a Middleware. For a simple example, look at what happens when there’s an error in your code:

Load that in your browser via bundle exec rackup. It will show the default Rack error page. But what if you want a fancier page? There’s a middleware for that: ActionDispatch::ShowExceptions . It will allow us to show webpages to status errors so that the end-user doesn’t see code errors. It’s real simple to add, first add the files to a new folder “public”, and individual status codes like so:

You can get the HTML for those pages in the public example on Github.

Why is the folder called “public”? Because I said so. (It’s a Rails convention actually.)

Then add the following to your config.ru:

The new line means to use the middleware ActionDispatch::ShowExceptions, with the argument of “ActionDispatch::PublicExceptions.new(“public/”)”. In this case, ActionDispatch::ShowExceptions requires a secondary middleware to route to actually show the exception. The “public/” of course means to look for any files in our newly created public folder.

Then load your front page. It should now have a prettier error page:

It’s the little things that count.

So lets add some routing, so here’s our updated config.ru file:

So let’s go over what we did. First, we created a new RouteSet, which is fine, and then started to draw some routes. Notice how the routes mention a “mainpage#index” or “mainpage#show”? It means that to route that to a MainpageController#index or MainpageController#show action. Why does it add Controller to the class name? Because I say so.

On the MainpageController is a self.action handler to handle the route internals by creating a new instance. And the individual methods now look like before with the status, header, body like in the other example.

Towards the end we add ActionDispatch::DebugExceptions to show the errors in the log in our terminal, because errors are now hidden from the browser. And finally, our app is no longer a function but rather the routes we created (which will forward to it’s respective controller).

Anyway, the routes are exactly like Rails routes, so a better documentation was written in the Rails Guide. There is some fancy pants stuff other than generating each individual route, like “namespace” which allows you to create namespaced controllers (like Admin::PostController for an admin interface), “resources” which creates the standard routes for an object (index, show, new, edit, create, update, destroy), and constraints by regex, subdomain, and more.

We’ll be going over the part of routes we’ll be adding as we add them. This just shows how routes fits in the whole scheme.

Download the working example code here: https://github.com/ROFISH/ruby_for_programmers/tree/master/10

So ends the really basic tutorial. There’s still tons more stuff to go over, like Modules and Mixins, Monkeypatching, Begin/Rescue/Ensure, but we’ll get to those basics as we come to them. If you really want to learn some deep dark mysteries, I suggest reading the Pickaxe Book. It’s a complete, unabridged, and also includes information about the standard library too.

So for now, we’re going to focus on creating a web app with Rails. There are other Ruby-based frameworks like Sinatra, we’re going to be focusing on Rails since it’s got, at least in my opinion, the right amount automagic for what we’re going to build. (Of course one could argue that Node or Java or some other language would be better. That’s not the scope of this, but to learn Rails.)

I’ve always found it better to learn Rails from the ground-up from its parts rather than a “here’s all the random things it can do!” that’s in most docs/tutorials. So to build a webpage from scratch, you must first invent the universe.

In which case, you must start with a Gemfile and Bundler. In the dayes of olde, gems were not included with Ruby, but rather a separate installation. These days, it’s included with the Ruby source as part of a standard installation. However, what’s missing is a package version manager, which is Bundler. You can install bundler as you would any other gem:

Bundler ensures that everybody is running the same version of gem as you, which is very important as APIs and functions changes, and helps ensure security updates by listing gem versions.

So for now, we’re going to create a Gemfile in our project and list Rack as a gem:

Bundler allows a bunch of configuration options in the Gemfile (which can be read in the Bundler docs). To note the current lines, the first tells Bundler to enforce a Ruby version. This is slightly helpful if you have a custom installation on a server, but especially helpful on cloud services like Heroku which otherwise wouldn’t know which Ruby version to use. (You don’t automatically want to use the latest and greatest because it might introduce bugs.) The second determines where the gems will download from (always rubygems.org). Then list the gems by name, and optionally by version. You can do the normal >, >=, <, <= tags, but ~> is special. It means that “incrementing the last number is okay, but not the others”. In this case Bundler can safely install 1.5.2, 1.5.3, 1.5.1052, but not 1.6.0. Also note that when installing on a server, Bundler will install the exact gem version you have from the Gemfile.lock file.

To install your gems just run bundle install from where your Gemfile is. This will create the Gemfile.lock which will tell servers and other programmers which version to use. If you’re missing a version, running bundle install will install it. If you wish to change a version, update the Gemfile and run bundle update rack or whatever the name of the gem to update. This will re-run the dependency check and put the new version in.

Once you have Rack installed, now it’s time to use it. While Rack can be called from a method like anything else, Rack apps typically have a “config.ru” file which is just a special file it looks for to operate.

So to create our first Rack app, just insert the following into a new config.ru file:

The first two lines tells Ruby to include rubygems, a holdover from the previously said days where gems is not included but good to do anyway. The second runs the Gemfile and includes all of its requested gems. Then we tell Rack to run a very simple app, which is already returned as an array with three elements: the HTTP status code (200 for page info, 404 for not found, etc.), the headers in a Hash, then the body of the response. Note that the body of the response has to respond to #each for metaprogramming and lazy-loading reasons we’ll go over later. Just for now, let’s make it a single element Array with a String.

To run your app, just run bundle exec rackup on the command line. (Bundle also ensures that you run the right version from the command line too, how nice!) Then just open your browser to localhost:9292 (or whichever port it chooses), and your page now loads! Nice, neat, easy simple. Except that every page is the same. Lets view what’s in the env variable:

Quit your app and restart to load new code. Reload the page to view all kinds of wonderful information:

So from here we can get the path requested and do things if we wanted to, like this:

It’s not pretty, but it does either show front page if you go to http://localhost:9292/ and a 404 error if you go to http://localhost:9292/asdf.

So right here off the bat, it’s going to show lots of things that are different if you are coming from a generic PHP side of things. PHP is generally a server plugin that operates based on which file is being requested. Even if you’re doing mod_rewrite stuff, it still generally just requests a file. Any changes to the file is fine, as the script is run on each page load.

Here though, it’s an app in the background that accepts a real HTTP connection. The app has to be running and any changes requires a restart of the app. It’s more of a tradeoff though: Large apps can keep it’s compiled code in memory and respond quicker vs. parsing scripting on each page load. For Ruby, since the code parsing for large apps is fairly slow, the server model is used.

Not all is lost, you can simply put your app behind a reverse proxy (Apache instructions, Nginx instructions). Now using straight Rackup and WEBrick (Ruby’s included web server in ruby) is not a good idea on the deploy-side. There’s better options for those that run your own servers, like Unicorn, Puma, Passenger, the latter available in both open-source and enterprise editions, and Heroku, Docker, and AWS Beanstalk on the cloud-side. We’ll be mostly focusing on app building rather than deployment for the most part.

In a language where everything is an object, then being able to create your own custom objects is a very powerful tool. Thus the below example:

And like any good OOP language, you can has inheritance:

On creation, it uses the #initialize function, rather than new. Note that it doesn’t matter what initialize returns, created an object via #new always returns the created object.

As an object, it’s main purpose is to hold data and to process it. Using the special “@” before a variable means to access an instance variable. Check this example:

@hp is an internal variable accessible within the instanced object. Unless you create a method for it, you cannot access that data from outside the object. (Well, I lied see below, but it’s really for debugging and not recommended for normal use:)

Combined, you can do some crazy things:

For the Animal, it works like normal. For the Dog, it’s hp is nil because the initialize step was overwritten and instead did not define the @hp. For the Cat, it returns an error because it requires the breed. The LolCat works because it provides the breed, runs the super function (which runs the function of it’s immediate ancestor class), and uses the #show_hp function from the super ancestor Animal.