Enterprise applications are considered to be complex to design and develop. Technologies such as J2EE and .Net augment this generalization. But there are technologies and frameworks that beg to differ. Ruby is one of those technologies/languages and Ruby-on-Rails (also called RoR) is such a framework.
Getting Started with Ruby on Rails - A Ruby-on-Rails Application, Step by Step (Page 3 of 4 )
Since any RoR application has to follow the MVC-Model II, the steps we must take involve the implementation of the three components of MVC. Yet the way the implementation goes, the components need not to be implemented from scratch as RoR has two points as guiding philosophies: DRY, or Don’t Repeat Yourself; and CoC, or Convention over Configuration.
The first point means that most of the code that gets repeated has been abstracted out into the framework. The second point means that all the management of the application is done by the framework on the basis of Conventions. The following are the steps essential for any kind of application to be developed:
1. Creation of Application structure.
2. Creation of the Controller.
3. Implementing the View.
4. Configuring the database.
5. Starting the server.
Of these, the fourth step comes into the picture only when the application requires database access. Each of these steps consists of one or more commands to create the corresponding components. So here is what’s to be done at each step:
Creation of the Application Structure
The first step in implementing any application is defining the directory structure in such a way that it reflects the components and the helping classes’ position within the application. For other frameworks, this has to be done by hand and linked with the framework by using the configuration files. In RoR, everything is done with a single command -- rails -- which takes the name of the application to be created as a parameter. There are configuration switches for the rails command but that will be discussed in the future. Coming back to creating the application structure, if the an application named demo has to be created, then change the directory where the structure has to be created and give the following command at the command line:
and RoR will respond by printing out the directory structure created like this:
If a dir (or ls based on the OS) is give inside the newly created directory, once the command is completed, one would see something like this:
The two directories of importance at present are “app” and “config.” The “app” directory contains the subdirectories having the files implementing the Controller and View logic of the application. At present these subdirectories contain nothing of importance. Hence the application is just skeletal. To make this skeletal structure work, a Controller is required. How to create a Controller is covered in the next step.
Creation of the Controller
Since the Controller orchestrates the application, without the Controller, it would be nearly impossible to make the application work. That’s true with RoR. So to create the Controller, RoR provides a command called generate. In reality, the generate command is a Ruby script in the “script” directory. This command has many more functions, which becomes the center point of the next step. For now, to create a controller named ‘Say’ in the “demo” (or whatever may be the application name) directory, the following command has to be issued:
ruby script/generate controller Say
The generate command takes the type of the MVC component as the first argument and the name of the component as the second argument. Here the type (constituent) of the MVC component is Controller and the name of the Controller is Say. On giving the command RoR responds with:
The significant aspect of the output is the three files and a directory that are generated: the directory “say” under app/view directory, the say_controller.rb under app/controllers directory and say_helper.rb under the app/helpers directory. Let's leave the “say” directory for now. The Controller say_controller.rb is the Controller of this application. Here also CoC comes into the picture. The Controller is suffixed with “_controller”. The next file is the say_helper.rb. It provides the services required by the Controller. If one looks at the say_controller.rb, the code would be something like this:
class SayController < ApplicationController
The above code means that the SayController is inheriting from the ApplicationController class. Each control action would have to be defined as a method of the SayController class. So to create a control action (or controller) called hello, one would have to define a method called hello as a member method of SayController class thus:
class SayController < ApplicationController
Now the Controller for the application demo is created. Though it does nothing much, it’s a beginning. The next step is creating the View component because without a corresponding View, the Controller’s orchestration proves nothing.
Implementing the View
To implement the View, RoR provides a templating technique in the form of RHTML, using which, the Ruby statements can be embedded into the HTML pages. To create the View, first an RHTML file is created. The name of the file has to be the same as that of the Controller. For example, to create a View for the Controller (or control action) hello, an RHTML file with the same name has to be created inside the app/view folder of the application. So the required RHTML file would be hello.rhtml. To make it more clear following could be the content of the file:
<h1>Hello from Rails! The time now is<%=Time.now%> </h1>
That completes the View part of the RoR.
Configuring the database
To configure a database connection for the application is as easy as changing two to three parameters in a file. But before that following things have to be done:
First, the database (or tablespace in Oracle's case) has to be suffixed with _development for development purposes, _test for testing purposes and _production for release purposes. For example, if the database name (for MySQL) is scm, then scm_development should be the name of database used for development, scm_test for debugging and scm_production for the release version of the database.
Then, the pure Ruby-based database driver is required for connectivity, otherwise connection time errors will be thrown during the database configuration step.
With these points in mind, let's look at database configuration using the database.yml file. When the application is created, RoR creates a database.yml file. The required database configuration has to be done here. Typically any database.yml will look like this:
The above configuration is for development purposes. That's all for database configuration.
Starting the Server
The server for RoR comes built into each application. The server resides inside the “scripts” folder. To start the server the command is as follows:
and the rails would give the something like the following output:
=> Rails application started on http://0.0.0.0:3000
[2005-02-26 09:16:43] INFO WEBrick 1.3.1
[2005-02-26 09:16:43] INFO ruby 1.8.2 (2004-08-24) [powerpc-darwin7.5.0]
[2005-02-26 09:16:43] INFO WEBrick::HTTPServer-start: pid=2836 port=3000
Ignore the dates. Just look at the port. It is 3000., and 0.0.0.0 is taken as the server address. It is the equivalent of localhost. Now to launch the application the following has to be typed at the address bar of any browser:
The interesting aspect is how the URL is formed. It says nothing about RHTML or the controller file. Instead it is using the name that we passed as a parameter to the generate script and the function created inside the controller class. In essence, the URL is of the form: