Redirects

The name says it all, really. Redirects are commands that you can use within the controller to skip (i.e., redirect) to other web pages.

 A redirect returns to the browser the response 302 Moved with the new target. So, each redirect does a round-trip to the browser and back.

Let’s create a new Rails project for a suitable example.

Before you can redirect, you need a controller with at least two different methods. Here is a ping-pong example:

The controller app/controllers/game_controller.rb has the content shown in Listing 4-1.

Now for the redirect: how can you set it up so you get immediately redirected to the method pong when you go to http://localhost:3000/game/ping? Easy, you say—you just change the route in config/routes.rb. And you are right. So, you don’t necessarily need a redirect. But if you want to process something else in the method ping before redirecting, then this is only possible by using a redirect_to in the controller app/controllers/game_controller.rb, as shown in Listing 4-2.

But what is game_pong_path? Let’s take a look at the routes generated for this Rails application:

 As you can see, the route to the action ping of the controller GameController now gets the name game_ping (see the beginning of the line). You could also write the redirect like this:

I will explain the details and the individual options of the redirect later in the context of each specific case. For now, you just need to know that you can redirect not just to another method but also to another controller or an entirely different web page.

When you try to go to http://localhost:3000/game/ping, you are automatically redirected to http://localhost:3000/game/pong, and in the log output you see this:

redirect_to :back

If you want to redirect the user of your web application to the page the user was just on, you can use redirect_to : back . This is useful in a scenario where your user first has to log in to get access to a specific page.

Flash Messages

In my eyes, the term flash messages is somewhat misleading. Almost anyone would associate the term flash with more or less colorful web pages that were implemented with the Adobe Shockwave Flash plug-in. But in Ruby on Rails, flash messages are something completely different. They are messages that are displayed on the new page after a redirect, for example (see the section “Redirects”).

Flash messages are good friends with redirects. The two often work together in a team to give the user feedback on an action just carried out. A typical example of a flash message is the system feedback when a user has logged in. Often the user is redirected back to the original page and gets the message “You are now logged in.”

As an example, here again is the ping-pong scenario from the section “Redirects”:

You fill app/controllers/game_controller.rb with the content shown in Listing 4-3.

Now you start the Rails web server with rails server and use the browser to go to http://localhost:3000/game/ping. You are redirected from ping to pong. But the flash message “Ping-Pong!” is nowhere to be seen. You first need to expand app/views/layouts/application.html.erb, as shown in Listing 4-4.

Now you see the flash message at the top of the page when you go to http://localhost:3000/game/ping in the browser, as shown in Figure 4-1.

If you go to http://localhost:3000/game/pong, you still see the normal Pong page . But if you go to http://localhost:3000/game/ping, you are redirected to the Pong page, and then the flash message is displayed at the top.

 If you do not see a flash message that you were expecting, first check in the view to see whether the flash message is output there.

Different Types of Flash Messages

Flash messages are “automagically” passed to the view in a hash. By default, there are three different types : error, warning, and notice. You can also invent your own category and then get it in the view later.

You can set a flash message by writing the hash directly too, as shown here:

Please take a look at the official documentation at http://guides.rubyonrails.org/action_controller_overview.html#the-flash for more information.

Why Are There Flash Messages at All?

You may wonder why there are flash messages in the first place. Couldn’t you just build them yourself if you need them? Yes, indeed. But flash messages have the advantage that they offer a defined approach that is the same for any programmer. So, you don’t need to start from scratch every single time you need one.

The Routes

rails generate scaffold has created a route (more on this later in Chapter 5), a controller, and several views for you.

You could also have done all of this manually. Scaffolding is merely an automatism that does the work for you for some basic things. This is assuming that you always want to view, create, and delete records.

Without diving too deeply into the topic of routes, let’s just take a quick look at the available routes for the example. You need to run rails routes.

These are all the routes and consequently URLs available in this Rails application. All routes invoke actions (in other words, methods) in the ProductsController.

The Controller

Now it’s about time you had a look at the file app/controllers/products_controller.rb. The scaffolding automatically creates the methods index, show, new, create, update, and destroy. These methods or actions are called by the routes.

Listing 4-5 shows the content of app/controllers/products_controller.rb.

Let’s take a moment and go through this controller.

The Views

Now you start the Rails web server.

A little drum roll, please, for dramatic suspense...launch the web browser and go to the URL http://localhost:3000/products. You can see the list of products as a simple web page, as shown in Figure 4-2.

If you now click the link New Product , you will see an input form for a new record, as shown in Figure 4-3.

Use your browser’s Back button to go back and click the Show link in the first line. You will then see the page shown in Figure 4-4.

If you now click Edit , you will see the editing view for this record, as shown in Figure 4-5.

If you click Destroy on the index page, you can delete a record after confirming the message that pops up. Isn’t that cool? Within less than ten minutes, you have written a web application that allows you to create, read/retrieve, update, and delete/destroy records. That is the scaffolding magic . You can save a lot of time.

form_for

In the partial used by new and edit, called app/views/products/_form.html.erb, you will find the code shown in Listing 4-7 for the product form.

<%= form_with(model: product, local: true) do |f| %>

  <% if product.errors.any? %>

    <div id="error_explanation">

      <h2><%= pluralize(product.errors.count, "error") %> prohibited this product from being saved:</h2>

      <ul>

      <% product.errors.full_messages.each do |message| %>

        <li><%= message %></li>

      <% end %>

      </ul>

    </div>

  <% end %>

  <div class="field">

    <%= f.label :name %>

    <%= f.text_field :name %>

  </div>

  <div class="field">

    <%= f.label :price %>

    <%= f.text_field :price %>

  </div>

  <div class="actions">

    <%= f.submit %>

  </div>

<% end %>

Listing 4-7

app/views/products/_form.html.erb

In a block, the helper form_for takes care of creating the HTML form via which the user can enter the data for the record or edit it. If you delete a complete <div class="field"> element here, this can no longer be used for input in the web interface. I am not going to comment on all possible form field variations at this point. The most frequently used ones will appear in examples later and be explained then (if they are not self-explanatory).

 You can find an overview of all form helpers at http://guides.rubyonrails.org/form_helpers.html .

When using validations in the model, any validation errors that occur are displayed in the following code at the head of the form:

<% if product.errors.any? %>

  <div id="error_explanation">

    <h2><%= pluralize(product.errors.count, "error") %> prohibited this product from being saved:</h2>

    <ul>

    <% product.errors.full_messages.each do |message| %>

      <li><%= message %></li>

    <% end %>

    </ul>

  </div>

<% end %>

Let’s add a small validation to the app/models/product.rb model , as shown in Listing 4-8.

class Product < ApplicationRecord

  validates :name,

            presence: true

end

Listing 4-8

app/models/product.rb

Whenever somebody wants to save a product that doesn’t have a name, Rails will show the flash error in Figure 4-6.

JSON As Default

Right at the beginning of app/controllers/products_controller.rb you will find the entry for the index action, as shown in Listing 4-10.

# GET /products

# GET /products.json

def index

  @products = Product.all

end

Listing 4-10

app/controllers/products_controller.rb

The code is straightforward. In the instance variable @products, all the products are saved. The view app/views/products/index.json.jbuilder contains the code shown in Listing 4-11 to render the JSON.

json.array! @products, partial: 'products/product', as: :product

Listing 4-11

app/views/products/index.json.jbuilder

It renders the partial named _product.json.jbuilder, as shown in Listing 4-12.

json.extract! product, :id, :name, :price, :created_at, :updated_at

json.url product_url(product, format: :json)

Listing 4-12

app/views/products/_product.json.jbuilder

You can use your browser to fetch the JSON output. Just open http://localhost:3000/products.json and view the result. I installed a JSON view extension in my Chrome browser to get a nicer format, as shown in Figure 4-7.

If you do not want the JSON output, you need to delete the json.jbuilder files.

Example for a Minimal Project

Let’s assume you need a web page quickly with which you can list products and represent them individually. But you do not require an editing or deleting function. In that case, a large part of the code created via scaffolding would be useless and have to be deleted. Let’s try it as follows:

Now create db/seeds.rb with some demo products , as shown in Listing 4-14.

Populate it with this data :

Because you need only index and show, you should delete the views that not required.

The json.jbuilder views are not needed either.

The file app/controllers/products_controller.rb can be simplified with an editor. It should look like Listing 4-15.

You only need the routes for index and show . Please open the file config/routes.rb and edit it as shown in Listing 4-16.

A rails routes command shows you that really only index and show are routed now.

If you now start the server with rails server and go to the URL http://localhost:3000/products, you get an error message , as shown in Figure 4-8.

The same message will be displayed in the log.

The error message states that you call the undefined method edit_product_path in the view app/views/products/index.html.erb. Because you route only index and show now, there are no more edit, destroy, or new methods anymore. So, you need to adapt the file app/views/products/index.html.erb in the editor as shown in Listing 4-17.

While you are at it, you can also edit app/views/products/show.html.erb accordingly; see Listing 4-18.

Now the application is finished. Start the Rails server with rails server and open the URL http://localhost:3000/products in the browser, as shown in Figure 4-9.

 In this example, I am not commenting on the required changes in the tests, as this is not an exercise for test-driven development (TDD) but is meant to demonstrate a way of working with scaffolding. TDD developers will quickly be able to adapt the tests.

Conclusion

Try working with scaffolds one time and without them the next. Then you will soon get a feel for whether they fit into your workflow. I find that scaffolding makes my work much easier for standard applications.