Create a Rails Project

Before you even get going, please check that you are using Rails 5.2.

That’s looking good. If you have an older version of Ruby or Rails installed, please install the 5.2 version before you read any further. The command gem install rails installs the current Rails version , and gem install rails --pre installs the beta of the next version.

Now you start by creating a new Rails project with the name testproject. Ruby on Rails is a framework, so you first need to set up the corresponding directory structure and basic configuration, including several scripts. It’s as easy as pie; just use the command rails new testproject to create everything you need.

Next, you cd into the new directory and run the first migration to create Active Storage tables.

 You don’t need to run rails db:migrate, which runs open database migrations at this time, but it is a good habit to make sure all database migrations are done.

You can check whether the new Rails application is working by launching the integrated web server.

 Depending on the operating system (for example, macOS) and on your firewall settings, you may see a pop-up window when first starting a Rails application asking you if the firewall should permit the corresponding connection .

The start of the Rails application is looking good, so go to the URL http://localhost:3000 in your web browser (see Figure 2-1).

Looks good. Rails works fine.

 You can stop the web server with the key combination Ctrl+C.

Static Pages

There are certain static pages , images, and JavaScript files that are automatically delivered by Rails. Remember the following part of the output of the command rails new testproject?

The directory name public and the files it contains already look very much like static pages. Let’s create the file public/hello-world.html with the content shown in Listing 2-1.

Now start the Rails web server with rails server.

You can take a look at this web page at the URL http://localhost:3000/hello-world (see Figure 2-2).

No output in the log means that this page was not handled by the Rails framework. It was delivered directly from the web server, which is Puma in this case.

 You can of course also use the URL http://localhost:3000/hello-world.html. But Rails regards HTML and therefore the file ending .html as standard output format, so you can omit the .html extension here.

Now you know how you can integrate fully static pages in Rails. This is useful for pages that never change and that you want to work even if Rails is not currently working, for example because of an update. In a production environment, you would usually put a classic web server such as Apache or Nginx in front of the Rails server, which is capable of autonomously delivering static files from the public directory .

Programming in an erb File

erb pages can contain Ruby code. You can use erb to program and give these pages dynamic content.

Let’s start with something simple: adding 1 and 1. First try the following code in irb:

That was easy.

 If you want to output the result of Ruby code in erb, enclose the code within <%= ...%>.

Fill the erb file app/views/example/test.html.erb as shown in Listing 2-5.

Then use rails server to launch the web server.

Visit that page with the URL http://localhost:3000/example/test, as shown in Figure 2-3.

You may ask yourself, how can the result of adding two Integers be displayed as a String? Let’s first look up in irb if it really is an Integer.

Yes, both the number 1 and the result of 1 + 1 is an Integer. What happened? Rails is intelligent enough to automatically call all objects in a view (that is, the file test.html.erb) that aren’t already strings via the method .to_s, which always converts the content of the object to a string. Let’s take a brief trip to irb.

You are now going to learn the finer points of erb step-by-step. Don’t worry, it’s neither magic nor rocket science.

<% ... %> vs. <%= ... %>

In the .html.erb file, there are two kinds of Ruby code instructions in addition to the HTML elements.

• <% ... %>: Executes the Ruby code it contains but does not output anything (unless you explicitly use something like print or puts in special ways).

• <%= ... %>: Executes the Ruby code it contains and outputs the result as a String. If it’s not a String, the method to_s will be called.

 The output of <%= ... %> is automatically escaped. So, you don’t need to worry about “dangerous” HTML.

Let’s use an example to make sure it all makes sense. You use each to iterate through the range (0..5). Edit app/views/example/test.html.erb as shown in Listing 2-6.

<p>Loop from 0 to 5:

<% (0..5).each do |i| %>

  <%= "#{i}, " %>

<% end %>

</p>

Listing 2-6

app/views/example/test.html.erb

Open this view in the browser (see Figure 2-4).

Let’s now take a look at the HTML source code in the browser.

<!DOCTYPE html>

<html>

  <head>

    <title>Testproject</title>

[...]

  </head>

  <body>

    <p>Loop from 0 to 5:

  0,

  1,

  2,

  3,

  4,

  5,

</p>

  </body>

</html>

Now you understand how Ruby code is used in the view.

Layouts

The erb file in the directory app/views/example/ only forms the core of the later HTML page. By default, an automatically generated app/views/layouts/application.html.erb is always rendered around it. Take a closer look at it in Listing 2-7.

The interesting bit is the following line:

With <%= yield %>, the view file is included here. The lines with the stylesheets , the JavaScript, and csrf_meta_tags can stay as they are for now. You’ll take a look into that in the asset pipeline in Chapter 13. There’s no need to bother with that right now.

The file app/views/layouts/application.html.erb enables you to determine the basic layout for the entire Rails application. If you want to enter a <hr> for each page and above it some header text, then you can do this between <%= yield %> and the <body> tag, as shown in Listing 2-8.

You can also create other layouts in the directory app/views/layouts/ and apply these layouts depending on the relevant situation. But let’s leave it for now. The important thing is that you understand the basic concept.

Passing Instance Variables from a Controller to a View

One of the cardinal sins in the MVC model is to put too much program logic into the view. That’s more or less what used to be done frequently in PHP programming. I’m guilty of having done it myself. But one of the aims of MVC is that any HTML designer can create a view without having to worry about the programming. Yeah, yeah...if only it were always that easy. But let’s just play it through in our minds. If I have a value in the controller that I want to display in the view, then I need a mechanism for this. This is referred to as an instance variable and always starts with @. If you are not 100 percent sure which variable has which scope, then please take another quick look at “Scope of Variables” in Chapter 1.

In the following example, you insert an instance variable for the current time that you get by Time.now in the controller and then insert it in the view. You’re taking programming intelligence from the view to the controller.

The controller file app/controllers/example_controller.rb looks like Listing 2-9.

In the view file app/views/example/test.html.erb, you can then access this instance variable, as shown in Listing 2-10.

With the controller and the view, you now have a clear separation of programming logic and presentation logic. Now you can automatically adjust the time in the controller in accordance with the user’s time zone, without the designer of the page having to worry about it. As always, the method to_s is automatically applied in the view.

I am well aware that no one will now jump up from their chair and shout, “Thank you for enlightening me! From now on, I will only program neatly in accordance with MVC.” The previous example is just the first small step in the right direction and shows how you can easily get values from the controller to the view with instance variables.

Partials

Even with small web projects, there are often elements that appear repeatedly, for example, a footer on the page with contact info or a menu. Rails gives you the option of encapsulating this HTML code in the form of partials and then integrating it within a view. A partial is also stored in the directory structure under app/views/. But its file name must start with an underscore (_).

As an example, you now add a mini footer to your page in a separate partial. Copy the content shown in Listing 2-11 into the new file app/views/example/_footer.html.erb.

 Yes, this is not the MVC way of doing it right. Date.today.year should be defined in the controller. I’m glad that you caught this mistake.

You can edit the file app/views/example/test.html.erb as shown in Listing 2-12 and insert the partial via the command render.

So, now you have the following files in the directory app/views/example:

The new web page now looks like Figure 2-5.

 The name of a partial in the code is always specified without the preceding underscore (_) and without the file extensions .erb and .html. But the actual file must have the underscore at the beginning of the file name and end with the file extensions .erb and .html.

Partials can also be integrated from other areas of the subdirectory app/views. For example, you can create a directory app/views/shared for recurring and shared content and create a file _footer.html.erb in this directory. You would then integrate this file into the erb code via the following line:

Passing Variables to a Partial

Partials are great in the sense of the Don’t Repeat Yourself (DRY) concept. But what makes them really useful is the option of passing variables. Let’s stick with the copyright example. If you want to pass the start year as a value, you can integrate this by adding the code in Listing 2-13 in the file app/views/example/_footer.html.erb.

<hr>

<p>

Copyright <%= start_year %> - <%= Date.today.year %> the Easter Bunny.

</p>

Listing 2-13

app/views/example/_footer.html.erb

So, let’s change the file app/views/example/test.html.erb as shown in Listing 2-14.

<p>Loop from 0 to 5:

<% (0..5).each do |i| %>

  <%= "#{i}, " %>

<% end %>

</p>

<%= render partial: "footer", locals: {start_year: '2000'} %>

Listing 2-14

app/views/example/test.html.erb

If you now go to the URL http://localhost:3000/example/test, you see the 2000.

Sometimes you need a partial that uses a local variable and need the same partial but without the local variable somewhere else. You can take care of this in the partial with an if statement, as shown here:

<hr>

<p>

  Copyright

  <%= "#{start_year} - " if defined? start_year %>

  <%= Date.today.year %>

  the Easter Bunny.

</p>

 defined? can be used to check whether an expression has been defined.

Now you can call this partial with <%= render partial: "footer", locals: {start_year: '2000'} %> and with <%= render 'footer' %>.

app

app is useful if you want to analyze things having to do with routing.

debug

In any view you can use the debug helper to render an object with the YAML format within a <pre> tag. To display the value of @foo, you can use the following line in your view:

Web Console

The web-console gem provides a way to render Rails console views. When you browse to a specific URL, at the end of that page you’ll get a console.

Let me show you this by example with this simple Rails application:

Rails 5.2 introduces a strict content security policy (CSP) that has to be configured to use the web console first. Please take a look at https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy to understand the concept of a CSP . You find your CSP configuration in the file config/initializers/content_security_policy.rb. Please configure it according to your security needs. Listing 2-17 shows a quick-and-dirty hack to display the use of web console . Please do not use this in production.

In app/controllers/page_controller.rb, you’ll add the code shown in Listing 2-18.

In the view app/views/page/index.html.erb, you’ll add the console command shown in Listing 2-19.

After starting the Rails application with rails server and browsing to the URL http://localhost:3000/page/index, you get a web console at the bottom of the page (see Figure 2-6). In it you have access to the instance variable @foo.

Other Debugging Tools

There are a couple of other built-in debugging tools that are out of the scope of this chapter. Please take a look at http://guides.rubyonrails.org/debugging_rails_applications.html to get an overview.

Don’t Repeat Yourself

Many Rails programmers are big fans of DRY . DRY means purely and simply that you should try to place repeated programming logic into separate methods.

Refactoring

You’ll often hear the word refactoring in the context of DRY. This involves functioning applications that are further improved. The application in itself remains unchanged in its interface. But its core is optimized through, among other principles, DRY.

Convention Over Configuration

Convention over configuration (also known as coding by convention ; see http://en.wikipedia.org/wiki/Convention_over_configuration ) is an important pillar of a Rails application. It states that the programmer does not need to decide in favor of certain features when starting a project and set these via configuration parameters. It specifies an underlying basic consensus, and this is set by default. But if you want to work outside of this conventional basic consensus, then you will need to change the corresponding parameters .

Model

Model in this case means data model. By default, Rails applications are an ActiveRecord data model (see Chapter 3).

All models can be found in the directory app/models/.

View

The view is responsible for the presentation of the application. It takes care of rendering the web page, an XML file, or a JSON file. A view could also render a PDF or an ASCII text. It depends entirely on your application.

You will find all the views in the directory app/views/.

Controller

Once a web page call has ended up in a route (see Chapter 5), it goes from there to the controller . The route specifies a certain method (action) as a target. This method can then fulfil the desired tasks (such as finding a specific set of data and saving it in an instance variable) and render the desired view.

All controllers can be found in the directory app/controllers/.