Ruby on Rails step by step. # 3 Controller and View

So, we finished the last step by letting RoR generate the first test application for us, and on its basis we will start to get acquainted with the capabilities of the framework. As we have said, the RoR application has a strictly defined structure, let's see what its folders are for:

• app : the dynamic part of your application
  controllers : interface and business logic
  helpers : Code to Support Views
  models : objects Models related to the database and used in the application
  views : templates for sending to remote user
  layouts : page layout files
• config : environment, database and application settings
  enviroments : configurations related to environments
  initializers : configuration files that are processed at server startup
• db : database schema in the form of Active Record migrations
• doc : your web application documentation
• lib : Ruby libraries related to the application
• log : log files
• public : the static part of your application
  stylesheets : CSS files
  javascripts : javascripts files
  images : image files
• script : Shell scripts for managing RoR projects
• test : code and data to test your application
  fixtures : data loaded into the database during testing
  functional : functional tests for checking controllers
  integration : integration tests
  unit : Unit tests for checking Models
• tmp : here Rais stores temporary data
• vendor : external libraries used by the application
  plugins: RoR plugins

A good tradition has become “Hello World” as an example of the operation of any PL or engine. Well, let's make a page that will greet us. We know that an application on RoR should consist of three components: View, Controller and Model. Say hello is easy, just pass the HTML-code to the browser. It is easy to guess that HTML should be contained in the View, but RoR does not allow you to create views directly, because the View must be directly associated with the Controller. To generate something in RoR, you need to go to the command line (we already know how to do it) and move to the application folder. Here we command:

ruby script/generate controller Hi index

script/generate is the Shell-script generate in the script folder, written in Ruby, so you need to run the script through an interpreter (for this we added ruby at the beginning of the command). We also passed two arguments to the script: the controller determines that it is necessary to generate the Controller code, in this case it will be called Hi - this is the second argument. And the index at the end of the command will bind to the controller. View index , which, in fact, we needed. We'll wait for the dumb, and this is what the script will give us:

exists app/controllers/<br>exists app/helpers/<br>create app/views/hi<br>exists test/functional/<br>create app/controllers/hi_controller.rb<br>create test/functional/hi_controller_test.rb<br>create app/helpers/hi_helper.rb<br>create app/views/hi/index.html.erb

Lines starting with exists show the folders and files that the generator wanted to create, but they were already in place. Knowing the folder structure, we can already say that the hi folder was created in Views, the Controller, the template for creating tests, the helper, and the View file index.html.erb (the .html.erb format is a combination of HTML and Ruby code).

Now the index become available for the application. Let's start the server and take a look at http://127.0.0.1 ل000/ hi/ :


')
Not terribly, but the page tells us that the file is in app/views/hi/index.html.erb . When you open it, you will notice that there is not even a basic HTML structure in the code. Let's add a little file and bring it into a more decent view:

< html >
< head >< title > Hi Habrahabr! </ title ></ head >
< body >
< h1 > Hello! </ h1 >
< p > app/views/hi/index.html.erb </ p >
</ body >
</ html >

Save the file and update the page:



Probably, all these generations of multiple folders look rather dubious enough to create an ordinary HTML page. To start using the RoR force, let's work with the app/controllers/hi_controller.rb . Here is what is in it:

class HiController < ApplicationController
def index
end

end

We already know Ruby, so the code will not frighten us: the HiController class has been HiController (note that the class name was generated based on the name of the Controller - this is CoC and we will also say why and why), which is a descendant of the ApplicationController class and the empty index method . Let us imagine with the method, setting variables in it and displaying them in the View. RoR uses instance variables (the ones that start with @ ) for this:

class HiController < ApplicationController
def index
@habr = 'Habrahabr'
@message = ' '
end
end

Respectively edit the View to show the variables:

< html >
< head >< title > Hi <%= @habr %>! </ title ></ head >
< body >
< h1 > Hello! </ h1 >
< p > app/views/hi/index.html.erb </ p >
< p > <%= @message %> </ p >
</ body >
</ html >

And here we see how Ruby's code is embedded in HTML. To display the value of a variable in the HTML code, we use the tags <%= … %> - this is the so-called expression.

To get the current time in Ruby, use the Time.now method. It’s enough to insert in HTML <%= Time.now %> , however, you should use the advantages of MVC and do the calculations in the Controller. Try “counting” the time in the Controller and display it on the View page.

Logic in View

We can also add some logic to View files, for example, to create lists, we can use iterators. Suppose we want to output the @message variable five times in paragraphs. We know how to do it in pure Ruby:

5. times do
puts "<p> #{@message} </p>" # ,
end

It remains only to remake the code in the .erb format, it turns out to be even somewhat simpler:

<% 5.times do %>
< p > <%= @message %> </ p >
<% end %>

puts replaced tags <%= … %> . And when we don’t need the output of the code, we simply omit = in the tags. That's what we did

How it works?

When code runs, RoR interprets the request. 127.0.0.1:3000/hi/ 127.0.0.1:3000/hi/ Hi as a call to the Hi Controller. RoR has an editable list of query routing rules, by default the first part of the query is the name of the Controller, the second is the method in it. Again, the index method is called by default, so we didn’t specify the method in the query. The method determines the necessary base variables. This completes the work of the Controller and RoR transmits data to the View. How does he know what kind of data to transfer to? Work conventions - the magic of naming conventions.

Epilogue

We superficially examined the interaction of the Controller and the View, learned how it passes and why it works, learned how to divide the logic between the View and the Controller. We will delve further into this topic - there are many interesting and important details here, but a little later. Comments are welcome in large quantities!