Sue Brandreth's Learning Resources

The router is the switchboard of your app, telling requests which controller action they’re supposed to run.

Introduction

The router is the doorman of your application. When an HTTP request arrives from the user’s browser, it needs to know which controller action (method) should be run. Should we display the “new user” webpage? Should we edit an existing user with whatever data got sent along?

The Router is basically just a matching service. It looks at the HTTP verb (GET, POST, PUT, DELETE) and the URL that it being requested and matches it with the appropriate controller action to run. It’s a pretty simple function but an essential one. If it can’t find a route that matches the request, your application will throw an error.

The other handy thing that goes on when a request enters your application is that Rails grabs all the parameters that came with it and makes them available for you in a special hash called params that you can later use in your controller. That’s good for things like form submissions so that you later can use that form data to create or modify objects.

If you open the routes file in your Rails app (located in config/routes.rb), you’ll see a huge mass of comments that do a pretty good job of explaining how it works, so you’re never in much danger of losing your way.

Lots of training courses and tutorials kind of gloss over routes, and they seem quite easy in hindsight.  Luckily, typing $ rake routes into the command line will give you an output of all the routes that are available to your application. In this section we’ll go into what’s actually happening with this file.

Points to Ponder

Look through these now and then use them to test yourself after doing the tasks

• What is the “Root” route?
• What are the seven RESTful routes for a resource?
• Which RESTful routes share the same URL but use different verbs?
• How do you specify an ID or other variable in a route?
• How can you easily write all seven RESTful routes in Rails?
• What is the Rails helper method that creates the HTML for links?

---

Root

The most important (and simplest) route in your file is the root url… where should users be deposited when they land on http://supercutekittenphotos.com? Just tell Rails which controller and action to map that route to, and it is so:

    root :to => "kittens#index"  #kittens controller, index action (method)

Remember, when we say “action” we really mean “the method inside the controller that is called that”, ie. the index action is just the index method that’s defined in the KittensController

---

 RESTful Routes

If you recall our earlier discussion about REST, there are basically seven main types of actions that you can (and should) do to a “resource”, or an object like a blog post or user – something with its own database model. From that discussion, they are:

1. GET all the posts (aka “index” the posts)
2. GET just one specific post (aka “show” that post)
3. GET the page that lets you create a new post (aka view the “new” post page)
4. POST the data you just filled out for a new post back to the server so it can create that post (aka “create” the post)
5. GET the page that lets you edit an existing post (aka view the “edit” post page)
6. PUT the data you just filled out to edit the post back to the server so it can actually perform the update (aka “update” the post)
7. DELETE one specific post by sending a delete request to the server (aka “destroy” the post)

The highlighted words correspond to standard Rails controller actions.

Each of these represents a “RESTful” route, and so it makes sense that you’ll need a way to write these in your Router file so the requests they represent are actually routed to the proper action of your controller (in this case, the “Posts” controller). One way to write them out would be the long way:

get "/posts" => "posts#index"
get "/posts/:id" => "posts#show"
get "/posts/new" => "posts#new"
post "/posts" => "posts#create"  # usually a submitted form
get "/posts/:id/edit" => "posts#edit"
put "/posts/:id" => "posts#update" # usually a submitted form
delete "/posts/:id" => "posts#destroy"

Each of these routes is basically a Ruby method that matches that particular URL and HTTP verb with the correct controller action. Two things to notice:

1. The first key thing to notice is that several of those routes submit to the SAME URL. They just use different HTTP verbs, so Rails can send them to a different controller action. That trips up a lot of beginners.

2. The other thing to notice is that the “id” field is prepended by a colon. That just tells Rails “Look for anything here and save it as the ID in the params hash”. It lets you submit a GET request for the first post and the fifth post to the same route, just a different ID:

/posts/1  # going to the #show action of the Posts controller
/posts/5  # also going to the #show action of PostsController

You will be able to access that ID directly from the controller by tapping into the params hash where it got stored.

---

 The Rails Way to Write Restful Routes

Rails knows you want to use those seven actions all the time so they came up with a handy helper method which lets you do in one line what we just wrote in seven lines in our resources file:

# in config/routes.rb
  ...
  resources :posts
  ...

That is a Ruby method which basically just outputs those seven routes we talked about before.

---

Rake Routes and Route Helpers

With that above line in my routes file, what do my routes look like? If you type $ rake routes on the command line, it’ll output all the routes your application knows, which look like:

    edit_post  GET  /posts/:id/edit(.:format)  posts#edit

You can see the incoming HTTP verb and URL in the middle columns, then the controller action they map to on the right, which should all be quite familiar because you just wrote it in the routes file. The (.:format) just means that it’s OK but not required to specify a file extension like .doc at the end of the route. It will just get saved in the params hash for later anyway. But what’s on the leftmost column? That’s the “name” of the route.

There are a lot of situations where you want to be able to retrieve the URL for a particular route, like when you want to show navigation links on your webpage (do NOT hard code the URLS, because you’ll be out of luck when you decide to change the URLs and have to manually go in and change them yourself). Rails gives you a helper method that lets you create links called link_to, but you’ll need to supply it with the text that you want to show and the URL to link it to.

    link_to "Edit this post", edit_post_path(3) # don't hardcode 3!

We’re jumping a little bit ahead, but in this case, the second argument is supposed to be a path or a URL, so we use the path helper method to generate that. edit_post_path(3) will generate the path /posts/3/edit.

Rails automatically generates helper methods for you which correspond to the names of all your routes. These methods end with _path and _url. path, as in edit_post_path(3), will generate just the path portion of the URL, which is sufficient for most applications. url will generate the full URL.

Any routes which require you to specify an ID or other parameters will need you to supply those to the helper methods as well (like we did above for edit). You can also put in a query string by adding an additional parameter:

    post_path(3, :referral_link => "/some/path/or/something")

Now the :referral_link parameter would be available in your params hash in your controller in addition to the normal set of parameters.

---

 Routes go to Controller Actions!

Just to emphasise that routes correspond directly to controller actions, a very simple sample controller which would fulfill the above routes generated by resources :posts might look like:

    # in app/controllers/posts
    class PostsController < ApplicationController

      def index
        # very simple code to grab all posts so they can be
        # displayed in the Index view (index.html.erb)
      end

      def show
        # very simple code to grab the proper Post so it can be
        # displayed in the Show view (show.html.erb)
      end

      def new
        # very simple code to create an empty post and send the user
        # to the New view for it (new.html.erb), which will have a
        # form for creating the post
      end

      def create
        # code to create a new post based on the parameters that
        # were submitted with the form (and are now available in the
        # params hash)
      end

      def edit
        # very simple code to find the post we want and send the
        # user to the Edit view for it(edit.html.erb), which has a
        # form for editing the post
      end

      def update
        # code to figure out which post we're trying to update, then
        # actually update the attributes of that post.  Once that's
        # done, redirect us to somewhere like the Show page for that
        # post
      end

      def destroy
        # very simple code to find the post we're referring to and
        # destroy it.  Once that's done, redirect us to somewhere fun.
      end

    end

---

 I Don’t Want All Seven Routes!

Sometimes you just don’t want all seven of the RESTful routes that resources provides. Easy, either specify just the ones you want using only or just the ones you DON’T want using except:

    resources :posts, :only => [:index, :show]
    resources :users, :except => [:index]

---

 Non-RESTful Routes

Of course, you don’t have to do everything the RESTful way. You probably should, but there are times that you want to make up your own route and map it to your own controller action. Just follow the examples we gave at the top for RESTful routes:

    get '/somepath' => 'somecontroller#someaction'

Of course, the config/routes.rb comments should be helpful to you here as well.

---

 Task

You should have a good sense of what’s going on in the routes file by now but probably also have plenty of questions. The Rails Guides to the rescue!

1. Read Rails Guides Rails Routing from the Outside In (http://guides.rubyonrails.org/routing.html). Look at Sections 1-2.5, 3.1-3.4, and 4.6

---

 Additional Resources

• See Code School’s Rails 4: Zombie Outlaws (https://www.codeschool.com/courses/rails-4-zombie-outlaws). Level 1 is free and goes into routes.

• See Code School’s Surviving APIs with Rails (https://www.codeschool.com/courses/surviving-apis-with-rails).  Level 1 is free and gets into REST, Routes, Constraints, and Namespaces.

---

Controllers are the middle managers of the whole process. They tell everyone else what to do and take all the credit.

    PostsController < ApplicationController
      ...
      def index
        @posts = Post.all
      end
      ...
    end

When the controller has figured out which data needs to be displayed, it’s the View’s job to turn that into some half-decent HTML.

Introduction

The view is really the simplest part of the MVC structure. At the basic level, it’s just a bunch of HTML boilerplate into which you insert the variables you’ve received from your controller and which will be sent to the browser. It’s your actual “webpage”. It will often have some snippets of code designed to properly present the variables it has received, for instance a loop that will display each one of the posts on your blog. Views are often called view templates.

Views live in the directory app/views/controller_name/action_name.html.erb, where controller_name is the name of the controller the view is linked to and action_name.html.erb is the corresponding method inside the controller that was run immediately prior to rendering the view.

So the Posts controller running the #index action will implicitly render the app/views/posts/index.html.erb view when it’s done. You can explicitly tell your controller to render a differently named view by passing it as a parameter to the render function in your controller, but why? This directory and naming structure helps you (and Rails) to always know where to find a given view.

To use an instance variable from your controller, just call it the same way you would in the controller: @user.first_name or @posts or @some_other_variable.

As always, in this lesson we’ll cover the high level content then ask you to read the Rails Guide for a more detailed understanding of how things work.

Points to Ponder

Look through these now and then use them to test yourself after doing the tasks

• What is a layout?
• What’s the difference between a “view template” and a “layout”?
• What is a “Preprocessor”?
• Why are preprocessors useful?
• How do you make sure a preprocessor runs on your file?
• What’s the outputted filetype of a preprocessed *.html.erb file? What about a *.css.scss file?
• What is the difference between the <%= and <% tags?
• What is a view partial?
• How do you insert a partial into your view?
• How can you tell that a view file is a partial?
• How do you pass a local variable to a partial?
• What’s the magical Rails shortcut for rendering a User? A bunch of Users?
• What are asset tags and why are they used?

---

 Layouts

The first thing to note is that the named view template we render from the controller is actually not the entire webpage. It doesn’t contain the <head> tags or the DOCTYPE declaration or some of the other basic structure that’s present in all pages. Precisely because those things are present in all of your pages, the Rails creators were smart enough to turn that code into its own file called a “layout”. Layouts live in the directory app/views/layouts.

For a brand new Rails application, the application.html.erb layout is pretty basic. It’s got the basic tags you need in all webpages (e.g. <html> and <body>) and a couple snippets of code that load up the javascript and css files your webpage will need. You’ll want to put anything that’s needed across all your webpages into the layout. Usually this is content like navbars and footers and snippets of code for displaying flash messages.

So if a layout is basically just a shell around the individual page, how does the page get inserted? That brings us back to the magic of the #yield method, which you saw when you learned about blocks (http://bedford-computing.co.uk/learning/ruby-on-rails/ruby-programming-odin-project-1/). The view template at app/views/posts/index.html.erb gets inserted where the yield statement is. When you get more advanced, you’ll be able to play around a bit with that statement but for now it’s just that simple.

---

 Preprocessors

The other thing you’ve undoubtedly noticed is the odd HTML code that goes inside <%= and %> tags. This is Embedded Ruby (ERB). It’s a special way of executing ruby code inside your HTML. HTML is static, so you need to dial in some Ruby if you want to do anything dynamic like looping, if statements or working with variables. ERB (and another similar language you might see called HAML) do exactly that.

What those tags do is execute whatever you see inside them exactly as if it was normal Ruby. So <%= "<em>I am emphasized</em>" %> will output an emphasized piece of text like <em>I am emphasized</em> and <%= @user.first_name %> will output joe.

The difference between <% and <%= is that the <%= version actually displays whatever is returned inside the ERB tags. If you use <%, it will execute the code but, no matter what is returned by that line, it will not actually display anything in your HTML template.

Most of your tags will be <%= because you’ll find yourself often just outputting important pieces of the instance variables that you received from your controller, like in the <%= @user.first_name %> example above. You use the <% for purely code-related stuff like if statements and each loops, where you don’t actually WANT anything displayed (the stuff you display will occur inside the loop).

If this is confusing, here’s an example. Say we want to display the first names of all the users in our application but only if the current user is signed in. This might look something like:

    <% if current_user.signed_in? %>
      <ul>
        <% @users.each do |user| %>
          <li><%= user.first_name %></li>
        <% end %>
      </ul>
    <% else %>
      <strong>You must sign in!</strong>
    <% end %>

Remember to close your statements and loops with <% end %>.

In the code above, if the user is signed in it will actually render to the web something like:

    <ul>
      <li>Bob</li>
      <li>Joe</li>
      <li>Nancy</li>
    </ul>

If the user isn’t signed in, it’ll be the much shorter:

    <strong>You must sign in!</strong>

In the above code, if we had accidentally used <%= in the loop line, e.g. <%= @users.each do |user| %> it would run the code fine, but because each returns the original collection, we’d also see a dump of our @users variable on our page (not very professional). It’ll happen to you several times and you’ll learn quick.

---

 How Do Preprocessors Work?

The important thing to note about the above code execution is that it is all done on the server BEFORE the final HTML file is shipped over to the browser (part of the Asset Pipeline, covered in the next lesson). That’s because, when you render your template in Rails, it first runs “preprocessors” like ERB. It knows you want to preprocess the file because it has the extension .html.erb.

Rails starts from the outside in with extra extensions. So it first processes the file using ERB, then treats it as regular HTML. That’s fine because ERB by definition outputs good clean HTML, like we saw above.

There are other preprocessors you’ll run into as well. .css.scss files use the SASS preprocessor and become regular CSS files. .js.coffee files, which the Coffeescript preprocessor, become regular Javascript after it is run. In both these cases, the preprocessor’s language makes your life easier by giving you some additional tools you can use (like having loops and working with variables) and compiles back down into a plain vanilla CSS or JavaScript or HTML.

The point is, there are many different preprocessors. They are usually gems that either already come with Rails or can easily be attached to it. Rails then runs them automatically, so all you have to worry about is whether your file has the right extension(s) to tell the preprocessor to run.

---

 View Partials

Another nice thing you can do in Rails is break apart your views into partials. This helps you on several levels — it makes your code more concise and easier to read, and also lets you reuse certain common patterns. One example is the form for creating or editing users. Both the #new and #edit actions need to render some sort of form for the user, and usually that form is almost exactly the same. So often people will turn that form into a new file called something like _user_form.html.erb and then just call that in both the new.html.erb and edit.html.erb view templates where it’s needed.

Pulling back a bit, partials are just HTML files that aren’t meant to be complete but can be shared by other files. You would call a partial by writing something like:

    # app/views/users/new.html.erb
    <div class="new-user-form">
      <%= render "user_form" %>
    <div>

There are a couple of syntax oddities you need to pay attention to. The view partial file is named with an underscore like _user_form.html.erb but gets called using just the core portion of the name, e.g. user_form in the example above.

If there is no directory specified in partial’s name, Rails will only look in the same folder as whichever view called it, ie. app/views/users. Sometimes it makes sense to share partials across multiple view templates that are in multiple controllers, so you save them in their own folder called app/views/shared and would then render them using the code <%= render "shared/some_partial"%>.

---

 Passing Local Variables to Partials

There’s a lot you can do with partials and we won’t dive into it all here, but the last thing that you might find yourself doing a lot is passing variables to partials. A partial has access to all the variables that the calling view template does, but do NOT rely on them! What if your partial is used by a different controller that uses a different structure for its instance variables? It’s bad code to expect an instance variable like @user to be there in the partial all the time. That means you’ve got to explicitly pass the partial whichever variables you want it to have access to.

In the example above, you most likely want to pass the @user variable to the partial so your code can render the right kind of form. render is just a regular method and it lets you pass it an options hash. One of those options is the :locals key, which will contain the variables you want to pass. Your code might change to look like:

    <%= render "shared/your_partial", :locals => { :user => @user } %>

To use the variable in your partial file, you drop the @ and call it like a normal variable.

---

 Implicit Partials

As usual, there are some things you would end up doing so many times that Rails has given you a short cut. One of these is the act of rendering a model object like a User or a Post. If you want a list of all your users, you could write out the HTML and ERB code for displaying a single user’s first name, last name, email etc many times directly in your app/views/users/index.html.erb file or you could keep that code in some sort of each loop.

But it’s usually best to make the User into its own partial called _user.html.erb so you can re-use it in other cases as well. The basic way of calling this might be something just like we saw above, which looks like:

    # app/views/index.html.erb
    <h1>Users</h1>
    <ul>
      <% @users.each do |user| %>
        <%= render "user", :locals => {:user => user} %>
      <% end %>
    </ul>

And in your partial:

    # app/views/_user.html.erb
    <li><%= "#{user.first_name} #{user.last_name}, #{user.email}" %></li>

It may seem strange to have only one line in a partial, but trust me that it usually doesn’t stay that way for long so it’s worth getting the hang of.

So if that’s the basic way, what’s the magical Rails way? Just tell it to render the User object directly, ie.

    # app/views/index.html.erb
    <h1>Users</h1>
    <ul>
      <% @users.each do |user| %>
        <%= render user %>     
      <% end %>
    </ul>

Rails then looks for the _user.html.erb file in the current directory and passes it the user variable automatically.

What if you want to render a whole bunch of users like we just did? Rails also does that for you the same way, saving you the trouble of writing out your own each loop like we did above. Simply write:

    # app/views/index.html.erb
    <h1>Users</h1>
    <ul>
      <%= render @users %>
    </ul>

In that situation, Rails not only finds the _user.html.erb file and passes it the correct user variable to use, it also loops over all the users in your @user collection for you.

---

 Helper Methods

rendering partials isn’t the only method you can call from within a view. Rails has a bunch of really handy helper methods that are available for you to use in the view. A few of the most common:

#link_to

`link_to’ creates an anchor tag URL. Instead of writing:

    <a href="<%= users_path %>">See All Users</a>

You write:

    <%= link_to "See All Users", users_path %>

It’s the Rails way. And recall that users_path generates a relative URL like /users whereas users_url generates a full URL like http://www.yourapp.com/users. In most cases, it isn’t an important distinction because your browser can handle both but make sure you understand the difference.

---

 Asset Tags

As you may have seen in the application layout file we talked about above, Rails gives you helper methods that output HTML tags to grab CSS or Javscript files. You can also grab images. These are called Asset Tags. We’ll get into the “Asset Pipeline” a bit later, but basically these tags locate those files for you based on their name and render the proper HTML tag.

    <%= stylesheet_link_tag "your_stylesheet" %>
    <%= javascript_include_tag "your_javascript" %>
    <%= image_tag "happy_cat.jpg" %>

Will render something like:

    <link href="/assets/your_stylesheet.css" media="all" rel="stylesheet">
    <script src="/assets/your_stylesheet.js"></script>
    <img src="/assets/happy_cat.jpg">

Note: in production, your stylesheet and javascripts will all get mashed into one strangely-named file, so don’t be alarmed if it’s named something like /assets/application-485ea683b962efeaa58dd8e32925dadf

---

 Forms

Rails offers several different helpers that help you create forms, and we’ll go over those in depth later.

---

 Your Tasks

Now that you’ve got a taste of the high level content, read through the Rails Guides for a more detailed look at things. The chapter below will actually start in the controller, where you need to let it know WHICH view file you want to render. The second half of the chapter gets more into the view side of things.

1. Read the Rails Guides Layouts and Rendering in Rails (http://guides.rubyonrails.org/layouts_and_rendering.html) Sections 1 through 3-4.  You can certainly skim when they start going over all the many different options you can pass to a given function. It’s good to know what they are and where you can find them, but you don’t need to memorize all of them.

---

 Conclusion

Views in general make up the user-facing side of your app. It can be a bit tricky at first to imagine how you choose which view to render, what to include in that view and how to use partials, but a few iterations of working with Rails will show you the conventions pretty quickly. Views will become second nature to you.

---

 Additional Resources

• Read {cl} Codelearn’s Rails views, layout, helper methods & assets pipeline (http://www.codelearn.org/ruby-on-rails-tutorial/introduction-views-layouts-helpers-assets-pipeline)

---

This lesson explains how Rails handles all the behind-the-scenes activities to get your CSS, JavaScript and Image files served quickly and efficiently and how you can use that process.

---

 Introduction

You’ve learned about Models, Views, and Controllers. That’s the nuts and bolts, but we’ve got plenty of material to cover which makes Rails much more useful to you. In this lesson, we’ll talk about the Asset Pipeline and a few other topics that don’t necessarily fit well in other sections but are important.

Look through these now and then use them to test yourself after doing the tasks

• What is the “Asset Pipeline”?
• What are “Manifest Files”?
• Why would you namespace your stylesheets?
• What does it mean to “Escape” HTML?

---

 The Asset Pipeline

Assets in your application are additional files that get called by the browser after your initial gob of HTML is received. They include things like CSS stylesheets, JavaScript files, images, videos etc. – basically anything that requires an additional request to get it.

Often, it’s easiest to organize your code for development purposes into many different files so you can keep track of them better. But if the browser has to use a dozen different CSS files, each one of those requests is going to slow things down. Too many requests and you’ve harpooned your user’s experience with your application.

A similar organizational issue has to do with storing things like images. It’s easier to keep them separate and separated in your directory but you want them to be really simple to link to so your image tags are robust.

Rails’ solution to these problems is to flatten everything out and mash all your asset files together into one big one for each file type (called “concatenation“). The process used to do this is the Asset Pipeline. For your CSS files, this means that Rails will take all the individual .css files and just stack them on top of each other in one giant asset file. It will then run an “uglifier” or “minifier” program on the file to remove extraneous spaces and make everything nice and small for shipping to the browser.

JavaScript files are the same.  All of them get put together and then uglified before being shipped to the browser as one single file. It’s better to have one slightly larger file than to make several full HTTP requests.

---

 Manifest Files

Rails needs to know which files to include , so it uses so-called “manifest” files to determine this. Your JavaScript manifest file will be app/assets/javascripts/application.js. It looks commented out, but the lines starting with //= tell Rails which files to go find and include. The comments in the file are pretty useful.  They say:

// This is a manifest file that'll be compiled into application.js, which will include all the files
// listed below.
//
// Any JavaScript/Coffee file within this directory, lib/assets/javascripts, vendor/assets/javascripts,
// or vendor/assets/javascripts of plugins, if any, can be referenced here using a relative path.
//
// It's not advisable to add code directly here, but if you do, it'll appear at the bottom of the
// compiled file.
//
// Read Sprockets README (https://github.com/sstephenson/sprockets#sprockets-directives) for details
// about supported directives.
//
//= require jquery
//= require jquery_ujs
//= require turbolinks
//= require_tree .

The require_tree helper method just gets everything in the current directory.

Your stylesheet manifest file operates on the same principle. It’s available at app/assets/stylesheets/application.css.scss:

/*
 * This is a manifest file that'll be compiled into application.css, which will include all the files
 * listed below.
 *
 * Any CSS and SCSS file within this directory, lib/assets/stylesheets, vendor/assets/stylesheets,
 * or vendor/assets/stylesheets of plugins, if any, can be referenced here using a relative path.
 *
 * You're free to add application-wide styles to this file and they'll appear at the top of the
 * compiled file, but it's generally better to create a new file per style scope.
 *
 *= require_self
 *= require_tree .
 */

Again, you see the require_tree helper method which brings in all CSS files in the current directory.

Reading the comments, you can also see that a couple other directories are assumed to be a “local directory” and can be easily referenced as well, like the lib/assets and vendor/assets files. Sometimes, if you start using a new gem (like some of the Twitter-Bootstrap gems) you manually need to add the new bootstrap stylesheets and JavaScripts to the manifest files to make sure your application actually includes them in the final output.

---

 The Output

Speaking of final output, what is it? Well, Rails mashes all the specified files together and creates a new one called something like: application-1fc71ddbb281c144b2ee4af31cf0e308.js. That nonsensical string of characters is meant to differentiate between files if you end up making any changes. If they were just called something like application.js, then your browser would cache it and never know to ask you for the latest version because it’s always named the same thing.

But wait, how does the browser know to go looking for application-1fc71ddbb281c144b2ee4af31cf0e308.js? That’s what the asset tags we talked about in the previous lesson are useful for. When you write in your application layout <%= javascript_include_tag "application" %>, Rails automatically knows which filename to request to get all your JavaScripts properly imported.

---

 Taking This Into Account in Your Code: Namespacing

This sounds great and wonderful and faster for your application, but does it change anything you do? Oftentimes you can just forget about the manifest files and keep coding along your way. For your initial applications, you might keep all the styles and JavaScripts in one file anyway, so it’s not going to change anything on your end.

It becomes important when, for instance, you have a ton of different pages that likely want to use different stylesheets. What if you want the .container class to do slightly different things in your user login pages versus the checkout pages? With the asset pipeline, Rails will jam all those files together and you can’t be sure which .container styles are going to override which others.

In theory, you could override styles from your stylesheets stored at app/assets/stylesheets with either inline styles or <style> tags, but that gets really messy and totally defeats the purpose of having external stylesheets for keeping code clean.

Let’s also assume that you really like user .container classes to keep your <div> elements neatly organized. The solution is to use “Namespacing“, which means that you basically nest your beneath some sort of variable or function name. This is actually a principle that gets used a LOT, so it’s important to understand it. You’ll see it with stylesheets, JavaScripts, modules of code and more.

The basic idea is to be able to say “all this code/css/whatever inside here only belongs to XYZ”. You sort of fence it off. It’s best explained with an example:

    # app/views/users/show.html.erb
    <div class="user">
      <div class="container">
        
      </div>
    </div>

Now this container and all the code inside of it is also within the .user class. So we can set up our stylesheet to specifically address the .container class that’s inside a .user class:

    # app/assets/stylesheets/user.css.scss
    # Note: I'm not going to use SCSS code because we haven't covered it yet
    .user .container{
      // style stuff
    }

This is good because we’re now specifically targeting containers used by User pages.

The same principle applies to JavaScript, and this will be covered later.

So any time you want to make only a portion of your stylesheets or JavaScript code available to a specific set of views, try namespacing it.

---

 Rails in Development

The asset pipeline functions a bit differently in development mode. If you look at your Rails server output when you’re working with a webpage in the local environment, it actually sends out many  stylesheets and the like. This is just to give you the ability to debug easier.

---

 Images

For images, the asset pipeline keeps them in the /assets directory unless you’ve made your own subdirectories. Use image_tag‘s to avoid confusion, e.g. <%= image_tag "fuzzy_slippers.jpg" %>.

---

 Preprocessors

Remember the preprocessors we talked about in the previous lesson on Views? Filetypes like ERB and SASS and HAML and Coffeescript all get preprocessed as part of the pipeline.

---

 

Un-Escaping HTML

Let’s say you’re building a blog and you want to be able to write posts that include HTML code. If you just write something like this is the <strong>BODY</strong> of my post and then try to display it in a view later, the <strong>tags will just be regular text… they will literally say ‘<strong>’. That’s called “escaping” the characters.

To get your views to actually render HTML as HTML, you need to let Rails know that the code is safe to run. Otherwise, it’s easy for a malicious attacker to inject code like <script> tags that cause major issues when you try to render them.

To tell Rails a string is safe, just use the method raw in your view template, for example:

<%= raw "<p>hello world!</p>" %>   

If you don’t want to rely on Rails’ native behavior and would like to make absolutely sure the HTML does not get run, use the CGI class’s escapeHTML method, e.g.

    CGI::escapeHTML('usage: foo "bar" <baz>')
    # => "Usage: foo &quot;bar&quot; &lt;baz&gt;"

---

 Your Tasks

1. Read the Rails Guides The Asset Pipeline (http://guides.rubyonrails.org/asset_pipeline.html ) Sections 1 to 3

---

The Asset Pipeline isn’t something that you often think about, especially when just building little toy apps, but it becomes important to understand as soon as you want to deploy your application or work with anything but the vanilla asset structure.

---

Additional Resources

• Look at Ryan Bates Understanding the Asset Pipeline (http://railscasts.com/episodes/279-understanding-the-asset-pipeline?view=asciicast)

• Read Stack Overflow’s How to html encode/escape a string (https://stackoverflow.com/questions/692921/rails-how-to-html-encode-escape-a-string-is-there-a-built-in)

---