Data transfer parsing of MVC structure in Ruby on Rails _ruby topics

If the reader has developed a rails based application, but there is a lot of confusion about the data transfer between MVC, congratulations, this article is about summarizing the methods and techniques of the rails data transfer. Ruby on Rails 3 (collectively, rails 3) is the current major release, and the content and code described in this article are based on this version.
Rails 3 Introduction

Ruby on Rails is a ruby-enabled, open source Web application Development framework with MVC patterns that delivers a full range of solutions for Web applications. Its "Custom convention is superior to configuration" design philosophy, so that Web developers can be freed from the cumbersome configuration, focus on the core application logic. "Custom is better than configuration" is Rails, based on best practices, provides directly-used functionality and specifications, and no longer requires developers to use complex configuration files for specific cumbersome settings. Ruby on Rails's fast and high quality development features and its numerous free plug-ins have attracted a large number of Internet upstarts, including Twitter, Groupon and Hulu.

Quickly create a Rails 3 application

To step through the functionality features of Rails 3, here is an incremental model for developing a simple blog model. After RAILS3 is installed, run the command: Rails new Demoblog.

Demoblog the types of files required by the application are automatically generated. Enter the generated folder Demoblog to run the command to automatically install the gem required by Demoblog: Bundle install.

Then simply configure the database file in the $rorails/demoblog/config/database.yml and run the command to create the database: Rake db:create.

Now that the simple Demoblog is created, run the server startup command: Rails server.

Open http://localhost:3000 to see the typical Welcome page for Rails 3, as shown in Figure 1.
Figure 1. Typical Welcome page for Rails 3

Rails Scaffolding can quickly build models, views, and controllers for new resources without having to deal with the details. Run the following command directly to create a article scaffold for Demoblog to manage the blog posts. Run Scaffolding Build command: Rails Generate scaffold Article title:string keywords:string content:text

This generates a article controller, a article view file, and a article model containing the title, keyword, and content three attributes. Run the Database Migration command to generate the related data table: Rake db:migrate. At this point, a simple but complete structure of the article management system is developed. Through url:http://localhost:3000/articles/, you can access its article management page directly.

Rails 3 MVC Architecture Resolution

Rails 3 implements the core functionality module with MVC (model model, view views, Controller Controller) hierarchy. This not only makes the business logic independent of the user interface, the code is clear and easy to maintain, it can improve the reuse of code, and achieve the Rails "do not repeat themselves" principle. The functions of MVC in Rails are as follows:

• Model: Represents the data information of the application system and the rules for manipulating the data;
• View: A user interface that represents an application system, usually an HTML file containing embedded Ruby code, for the work of providing data to browsers;
• Controller (Controller): primarily responsible for processing WEB requests, retrieving model data and passing data to the view as required. The controller is a bridge between the model and the view.

The Demoblog application created above, for example, users to access the article List, input page url:http://localhost:3000/article open the page, the corresponding WEB request processing process as shown in Figure 2, the approximate steps are as follows:

• The browser makes a WEB request
• The routing module sends the request information to the corresponding controller, and the controller decides how to handle the request;
• According to the request processing logic, the controller calls the corresponding model to complete the business logic.
• To retrieve or store the data according to the actual demand;
• The controller organizes the processing information and invokes the view to parse the data returned from the model;
• Complete the page rendering, return the data to the browser.

Figure 2. Rails 3 MVC Event processing flowchart

With the typical internal process of rails 3, you can see that the MVC structure of rails 3 is clear, and the division of labor is clear. So what are some of the techniques that are closely related to the data transfer? Many beginners are puzzled by this, the author will be in the following detailed analysis of the introduction.

Techniques for data transfer between controller and view

Open the View folder, find the source file used to implement the list of articles $rorails/demoblog/app/views/articles/index.html.erb, and see the code shown in Listing 1. This code @articles iteration of the variable, showing the property value of all the articles list.
Listing 1. View Index.html.erb Code Fragment

 <% @articles. Each do |article| %> 
 <tr> 
  <td><%= article.title%></td> 
  <td><%= article.keywords% ></td> 
  <td><%= article.content%></td> 
  <td><%= link_to ' show ', article% ></td> 
  <td><%= link_to ' Edit ', Edit_article_path (article)%></td> 
  <td> <%= link_to ' Destroy ', article,: Confirm => 
  ' Are you sure? ',: Method =>:d elete%></td> 
 > 
 <% End%>

What makes a beginner puzzled is where does the variable @articles come from? To solve this problem, open the source file of the article controller $rorails/DEMOBLOG/APP/CONTROLLERS/ARTICLES_CONTROLLER.RB and find the index method corresponding to Index.html.erb, You can see the variable @articles, as shown in Listing 2. The @articles variables in the view are generated by the controller and then passed to the view, and the delivery process is transparent to the developer. In other words, a view can directly use a variable of the corresponding method in the corresponding controller.
Listing 2. The code fragment that gets the data in the controller

 def index 
  @articles = Article.all 
  respond_to do |format| 
   format.html # Index.html.erb 
   format.xml {render:xml => @articles} 
  End 
 

The user opens http://localhost:3000/articles/new to publish a new article, the controller will pass @article = Article.new, based on the article model to create a null value of data, and then transmitted to New.html.erb View, the display effect is shown in Figure 3. Users fill out the data on this empty page and click "Create Article" to build the article. The article was created successfully, returning the message that the article was created successfully and the content of the newly created article, as shown in Figure 4. This looks like a simple process that actually includes the process of passing data from a form to a controller and then passing it to the model to complete the store.
Figure 3. New Create article

Figure 4. Article creation successful

The code that renders the view is located in _form.html.erb (called by New.html.erb). After the user clicks Submit, Rails jumps to the controller's create method according to the routing rules. The process is really simple, but how does the data that the user fills out to the form pass to the controller?

The Create method for the controller is shown in Listing 3 below. In order to create a new article object, the Create method reads the data from the params: article parameters. The params here is a hash table, one of the most important pass parameters in Rails, containing data that the browser requests to pass. It is this params that passes data from the client form to the controller. For example, the new article form data (including title,keywords,content) will be encapsulated into the article object and passed through params to the controller.
Listing 3. The Create method of the controller

 def create 
  @article = Article.new (params[:article]) 
  respond_to do |format| 
   If @article. Save 
    format.html { 
   redirect_to (@article,: Notice => ' article was successfully created. ')}
    format.xml { 
   render:xml => @article,: status =>: Created: Location => @article} 
   else 
    format.html { 
   render:action => "new"} 
    format.xml { 
   render:xml => @article. Errors,: Status =>: unprocessable_entity} end end 
 

The Rails application can pass data to params in two ways, which is then obtained by a method of the controller. One is to encapsulate data entered by the user into an HTML form into an HTTP request, and pass the data to the controller's params via a POST method. This is the approach used above to submit form data from the New.html.erb view to the POST method. Another way is to use the data as part of the URL, in the URL? Later, it is often called a URL query string parameter. Rails does not differentiate between the data passed by the two methods, and the controller can get the data from the params by the method described previously. Taking url:http://127.0.0.1:3000/articles?keywords%5b%5d=hello&keywords%5b%5d=test& Keywords%5b%5d=Article as an example, Params[:keywords] will store ["Hello", "Test", "Article"].

Technique of data transfer between controller and model

As shown in Figure 2, the controller is a key component of the connection view and model, which not only receives form data from the view, but also passes data from the model to the view. Compared with the data transfer between the controller and the view, it is easier to understand the data transmission between the controller and the model.

Reference Code Listing 3, the controller creates a Article instance through Article.new (Params[:article]) and then stores the data in a database table by @article. Save. This process is so simple that it seems that the controller is directly exchanged with the database and does not involve any models. Open the model source file $rorails/rorails/demoblog/app/models/article.rb, as shown in Listing 4. The model code is so concise that it doesn't even have a common attribute definition in the entity Relational model. In fact, the properties of a model in Rails are associated with a database field implementation by naming rules. The attribute definition of the model data is in the corresponding migrate file. Controllers directly use Create,save and update to inherit from the parent class activerecord::base to implement data creation, storage, and update without the need for additional coding.
Listing 4. Code for the Article model

 Class Article < ActiveRecord::Base end 
 

In Rails, the controller gets the model data process is also quite convenient and quick. Open the Controller source file and the Update method is shown in Listing 5. Rails passes the ID value in the request URL to the controller by params according to the routing rules. The Article.find method finds existing data based on the ID, and then updates the record using the Update_attributes method. The Rails controller reads data from the model precisely through the ActiveRecord find method.
Listing 5. Controller Update method

 def update 
  @article = Article.find (Params[:id]) 
  respond_to do |format| 
   If @article. Update_attributes (params[:article]) 
    format.html { 
    redirect_to (
    @article,: Notice => ' Article was successfully updated. ') } 
    format.xml {Head:ok} 
   else 
    format.html {render:action => ' edit '} 
    format.xml { 
    render:xml => 
    @article. Errors,: Status =>: unprocessable_entity} end end 
 

Rails 3 encapsulates the data mapping relationship between the controller, the model, and even the database, greatly simplifying the data manipulation process, making data access exceptionally convenient, and fully embodying the Rails "Custom conventions over Configuration" design philosophy.

Data sharing within a view
Data sharing between views and layouts

After Rails 3, the view layout generated through scaffolding is located in Layouts/application.html.erb and can be shared by all controllers. Layouts and views can share data from the controller. That is, the layout can get the data from the controller in exactly the same way as the view.

However, in some special cases, the layout needs to read some view information. Take Demoblog for example, to be able to display the total number of articles in the title of the article List display page, add the code at the end of Index.html.erb as shown in Listing 6.
Listing 6. View index reads the total number of articles

 <% content_for:articlenumber do%> 
 <%= @articles. Length%> <% end 
 %>

In the header of the layout source file, add the yield method, as shown in Listing 7. This <% the information in the Content_for:articlenumber do%> tag, which can be displayed at the location specified in <%= yield:articlenumber%>. The final display effect of the article's article Information in the page header is shown in Figure 5.
Listing 7. Display by layout source file

Figure 5. The final display effect of the total number of articles

The above examples are quite special, but they are a good illustration of how the layout reads the view data. It is important to note that the layout is not able to pass information to the view, because the view is executed before the layout is introduced or has a effect.
Data between Views

Rails have been carefully designed to pass data between views often. It not only provides a unique flash mechanism, but also supports the traditional session and Cookie functions. It should be noted that the data-passing process described in this section is essentially from a controller to a view. Because for the user, the data is fetched from a view and then displayed in a different view. Because the middle controller is almost transparent to the developer, this type is defined as data transfer between views.

The Rails flash mechanism is especially useful for passing data between the associated view pages. In essence, Flash is a hash table built in Rails to send a user's message to a view of another controller from one controller. When the controller calls Redirect_to, redirection clears all variables except Flash.

As an example of an article modification update, you need to tell the user the results of the next page (here is the page that displays the article, and the action for show). The corresponding Update method, as shown in Listing 5 of the preceding code, obviously updates the successful prompt message ' Article was successfully updated. ' Assignment to: notice, which is the most commonly used key to a flash hash table. In addition to: notice,: Error,: Alert, warning key is also quite common. Prompts the article to update the successful message display as shown in Figure 6.
Figure 6. Prompt article update success

Typically, data added to Flash can be read in the next request. However, in some cases, you want to use it directly in the current request. For example, if the article fails to create a page directly, it will not cause a new request. If you need to display the information in flash at this point, you can use the Flash.now method.

The use of flash must pay attention to several points: first, in order to ensure performance, flash stored data can not be too long. Second, Flash content can only span one redirect, and if you want the data to remain valid after redirection, you need to use flash.keep before redirecting.

To demonstrate how Rails uses cookies and sessions, this article adds the reader comment feature. The entire creation process is simple, and one of the following commands enables you to create a database table for comments and implement nested mappings:

Rails Generate model Comment user:string comment:text article:references

Run Migration Database command: Rake db:migrate, add comment display code to get the reader comment function shown in Figure 7.
Figure 7. Readers post comments

Cookies are usually text sent to browsers by the server to store small amounts of user information. Rails based applications do not require direct access to cookies in most cases because rails's built-in session mechanism or Third-party Plug-ins can support user information management. Data stored in cookies can be accessed across requests or even across sessions, so users can access the data directly using cookies.

Rails provides a very easy way to access cookies. To prompt the user for a comment using the same username, a Cookie is used here to save the user name that the user used when he last commented. Read or save the user name through Cookies[:name], as shown in Listing 8.
Listing 8. To create a controller code fragment for a comment

 Class Commentscontroller < Applicationcontroller 
 def create 
  @last_name = cookies[:name] 
  @name = params[ : Comment][:user] 
  unless @name = = @last_name 
   Cookies[:last_name] = @last_name 
   Cookies[:name] = @name 
  else 
   cookies[:last_name] = Nil end end 
 

In the article controller, as shown in Listing 9, it is convenient to read the data stored by Cookies. The comment page appears as shown in Figure 8.
Listing 9. Manipulating data through cookies

 def show 
  @article = Article.find (Params[:id]) 
  @last_name = Cookies[:last_name] 
  unless @last_name = = Nil 
  @name = cookies[:name] 
 End

Figure 8. Article Comment Display effect

Rails applications often use sessions to implement data transfer between multiple requests, and the session object can be used in both the controller and the view. Now we add a new session object to hold the list of names that the user has used. In Commentscontroller, the session object operates as shown in Listing 10.
Listing 10. Code fragment to manipulate data through session

  @names = Session[:name] 
  if @names 
   @names = [] 
  end 
  if @name 
   @names << @name 
  End Session[:names] = @names

In the view, add the code that displays the list of user names, as shown in Listing 11. The final display of the page appears as shown in Figure 9.
Listing 11. Code for the view to read the list of user names

 <% if @names%> 
 <p>the names you have used:</p> 
 <ul> 
 <% @names. Per do |name|% > 
  <li><%=h name%></li> 
 <% end%> 
 </ul> 
 <% End%>

Figure 9. Show user list on page

From the effect of implementation, flash, cookies and session can complete the data transfer between views. But Flash is generally used for simple hint messages, while cookies and sessions are common to user information management.

Conclusion

This paper introduces the MVC architecture of Rails 3, and then introduces the relationship between controller and view, controller and model and view, and analyzes the technique of data transfer in detail.