In this conclusion to a three-part series on how to do a project setup and proof of concept for a fictional bookstore on Ruby-on-Rails, we'll actually start the application for the first time and see how it functions. This article is excerpted from chapter one of the book Practical Rails Projects, written by Eldon Alameda (Apress; ISBN: 1590597818).
Testing a Book Emporium Application - How Does Ruby on Rails Work? (Page 3 of 6 )
Ruby on Rails is built around the Model-View-Controller (MVC) pattern. MVC is a design pattern used for separating an application’s data model, user interface, and control logic into three separate layers with minimal dependencies on each other:
The controller is the component that receives the request from the browser and performs the user-specified action.
The model is the data layer that is used, usually from a controller, to read, insert, update, and delete data stored, for example, in a relational database.
The view is the representation of the page that the users see in their browser; usually, the model is shown.
Figure 1-2 illustrates how a request from a browser is routed through the Ruby on Rails implementation of MVC. Ruby on Rails stores all MVC-related files in theappdirectory, which is located in the application root directory.
Figure 1-2. A request routed through the Rails framework
Implementing the About Emporium User Story
George has written the About Emporium user story on a piece of paper for us. He hands it over to us, and it reads as follows:
Emporium should have an About page where the contact details and a brief description of Emporium are shown to the user.
We do not yet know exactly what text should be shown on the About page, but we’ll first implement it, and then ask George again for more information when it is finished.
The requirement for the About Emporium user story is simply to display some description and the contact details for Emporium to the user. This is easy to implement and involves only two of the MVC layers: the controller and the view.
Running the Generate Script
First, we will jump-start the implementation of this requirement by using the generate script. Thegeneratescript can be used for quickly creating boilerplate code for controllers, models, and views or more complex functionality through third-party generators created by the Ruby on Rails community. The generated code usually requires modification to fit your requirements.
Run thegeneratescript with the following parameters to create theaboutcontroller,indexaction, and related files.
$ cd /home/george/projects/emporium $ script/generate controller about index
Thegeneratescript created a controller, view, helper, and a functional test for us. The controller has one action,index, which is called by default if no action is specified.
Next, openhttp://localhost:3000/aboutin your browser. You should see the About page we just created, as shown in Figure 1-3.
Figure 1-3.The About page generated by Rails
The “About#index” is computer-generated text, and the layout is ugly, so in the next section, we will spend some time modifying the code to fit our requirements.
As we told you earlier, thegeneratescript creates a functional test and a helper class. In our case, we will not use the functional test or the helper. In later chapters, we will teach you how to use the test-driven development technique to write not only functional tests, but also unit and integration tests.
Tip Helpers are useful for keeping your views clean and readable. Views shouldn’t contain complex logic and algorithms. Instead, you should refactor your view code and move the complex logic to a helper class. The methods in this class are automatically made available to the view. Using helpers will make your code easier to read and more maintainable.