Building Dynamic Web 2.0 Websites with Ruby on Rails

Ruby on Rails is an open-source web application framework ideally suited to
building business applications, accelerating and simplifying the creation of
database-driven websites. It has been developed on the Ruby platform.

This book is a tutorial for creating a complete website with Ruby on Rails (RoR).
It will teach you to develop database-backed web applications according to the
Model-View-Controller pattern. It will take you on a joy ride right from installation
to a complete dynamic website. All the applications discussed in this book will
help you add exciting features to your website. This book will show you how to
assemble RoR’s features and leverage its power to design, develop, and deploy
a fully featured website.

What This Book Covers

Chapter 1 gives you an overview of the features of Ruby and RoR, as well as
providing the various ways of installing, configuring, and testing both Ruby and
RoR.

Chapter 2 introduces you to the basics of Ruby as well as the main concepts
and components of RoR.

Chapter 3 makes you understand the design of tables according to the
conventions of RoR, creation of scaffolds for tables, and changing the scaffolds
according to the requirements.

Chapter 4 gives you details about how to set up the User Management module
for the website called TaleWiki.

Chapter 5 makes you familiar with the Login Management and Comment
Management modules for TaleWiki.

Chapter 6 introduces you to the Migrations and Layouts involved in setting up
the template for TaleWiki.

Chapter 7 describes the tagging functionality being implemented for the
enhanced search usability.

Chapter 8 provides you with the implementation of AJAX for TaleWiki.

Chapter 9 deals with the development of an interface for the administration.

Chapter 10 gives you the steps for deploying the website.

Gathering User Comments

In the last chapter, we saw how to set up User Management and Role Management
for TaleWiki. However, we did not set up the Login Management based on Users.
So, it was work only half done. To complete the task, we will set up Login
Management in this chapter. It will not only authenticate a user but also provide
the session management.

Secondly, we will look at how to gather user comments for a particular story. We
will start with the functionalities to be provided by the Comment Gathering module.
We will then move on to the database design for the module. After that we will not
only set up the Login Management but also modify the Tale Management so that
the User and Tales can be related. We will wrap up with the implementation of the
Comment Gathering module. Let’s gets started.

Understanding the Requirements

In this chapter, we will be tackling two problems—managing the user authentication
as well as the session management and accepting comments from other users for a
particular tale. So we can divide the requirements into two:

• Login Management
• Comment management

The Login Management module will also provide the solution to the problem of Tale
management that evolved during the development of User management. As the tales
table refers to the users table, without a user id a new tale cannot be submitted. The
Login management will provide us the user id corresponding to the new tales. Also,
it will tell us who has commented on a particular tale. Let us see how.

Login Management

As the name suggests, the main functionality the Login Management will provide
will be managing the logins. However, managing logins is not a single task. It is
dependent on others tasks or operations as well. So, the overall functionalities we
will be developing as part of Login management are:

• Authenticating the User: We can allow only the registered users to access
  the functionalities of TaleWiki. This operation will ensure that the user is a
  registered user before he or she tries to enter the TaleWiki.
• Setting the Session: Once the user is found to be authentic, then we have
  to maintain his/her authenticity until he/she logs out. The authenticity can be
  maintained by this functionality.
• Checking Roles: Each User is assigned a Role. So we will need to check
  whether a particular functionality—such as viewing details of another
  user—is a part of the Role. This functionality will check the User’s Role
  whenever he/she tries to access any functionality provided by TaleWiki.
• Invalidating Session: When a user logs out, all the details of the user in the
  current session need to be cleared out. This functionality will clear out all the
  details of the user, including whether the user is authentic or not.

Now that we have defined the functionalities of Login management, let us move on
to the next set of tasks—managing the comments.

Managing the Comments

It is natural for a person to comment upon whatever he or she reads. So, it is
necessary to provide a way for users to comment on a particular story. The
comments can be of two types—threaded and non-threaded. In threaded comments, one
comment can be posted as a response for another comment. If the first comment is
removed, then all its child comments will also be removed. If we go for non-threaded
comments, then each comment is considered an individual. So if one is deleted,
others are not affected.

The Comment Management module will do the same. The functionalities that the
Comment Management module will provide are:

• Adding a Comment: When a user wants to comment on a particular story,
  he or she can use this functionality. A user can comment on many stories.
  Comments are not threaded. That means a comment cannot be a response for
  another comment. Each comment is considered an individual.
• Deleting a Comment: If an administrator finds a comment offensive or feels
  that comments are very old, this functionality can be used to delete such
  comments. Only the administrator will have access to this functionality.
• Viewing Comments: Using this functionality, a user can read all the comments
  submitted for a particular story. It will be available for all users. In addition,
  the comments will be shown in the list view and the details view. In list view,
  the comments will be shown for each story, and in the details view, all the
  details including the date and complete text of the comment will be shown.

We are not providing a way to modify a posted comment. That is because comments
are considered one time and brief view of what the user thinks. Hence, no
functionality will be provided for the modification of comments. That wraps up the
requirements of the Login and Comment Management modules. Next, let us work
on the database design for the modules.

Designing the Database

As you would have already guessed, our next step will be designing the database.
However, unlike the modules that we developed previously, we will be designing
the database only for one of the two modules. The Login management module
doesn’t require a table because its functionalities are based on the users and roles
tables. So we will have to design the table for the Comment management module
only. Just like the previous chapter, the steps for designing the database are:

• Designing the E-R Model
• Deriving the Schemas
• Creating the Tables

Whenever a new module is added, some of the existing E-R models need to be
refined, and consequently the corresponding schemas and tables will be changed
accordingly. In the case of Comment management, this holds true as you will see as
we go through the steps. So here we go.

Designing the E-R Model

As the name suggests, the Comment Management module will have data related
to the comments submitted by the user. What is this data apart from the comment
itself? To answer this, first let us try to define the functionality of the Comment
Management module in one line. ‘Comment management will manage comments
submitted by a user for a particular story’—that’s how what will look like. The
important point here is ‘comments submitted by a user for a particular story’. We
have three main entities—Comments, Users, and Stories. Story and User entities
have already been discussed in Chapters 3 and 4. So let us look at the Comments
entity. The attributes for comments will include the date on which the comment has
been added and the title of the comment. In short, the Comments entity will have the
following attributes:

• Id—the unique number to identify each comment
• Comment body—the text of the comment
• Date—the date on which comment was added
• User—the user who has added the comment
• Story—the story on which the comment has been made

The entity diagram for the Comments entity will be as follows:

Coming back to our one line definition, we know that the User, Story, and Comments
entities are related. The question is how are they related? The answer is there in the
one line definition itself. First, let us consider the User entity. The definition says
‘comments submitted by a user’. That means one user can submit many comments.
Hence, the User entity has a one-to-many relationship with the Comments entity.
The relationship will be as follows in terms of an E-R diagram:

The next part of the definition tells us ‘comments for a story’. This means that one
story can have many comments. In other words, the Comments entity is related to
the Story entity through a many-to-one relationship. The Story entity will be at the
‘one’ end and the Comments entity will be at the ‘many’ end of the relationship. The
diagram will look like as follows:

When looking at all the entities with their attributes and relationships, the picture
will be as follows:

The next step obviously is deriving the schema. Here it comes.

Deriving the Schema

We have the complete information about the attributes and relationships of the
Comments entity. The main point about this entity is that unlike the User entity
it doesn’t introduce any changes in the existing schemas. The reason is that the
Comment entity is dependent on other entities and not vice versa. The schema will
be as follows:

Here Story and User both have their own schemas. So their Ids will be the foreign
keys in the table. Now, we can develop the table.

Creating the Tables

There is only one table to be created. Apart from the attributes, the comments table
(keeping with the naming convention), will have two foreign key references—one to
the users table and another to the tales table. Including these, the SQL query will be
as follows:

	CREATE TABLE `comments` (
	`id` INT NOT NULL AUTO_INCREMENT PRIMARY KEY ,
	`comment_body` TEXT NOT NULL ,
	`submission_date` DATE NOT NULL ,
	`tale_id` INT NOT NULL,
	`user_id` INT NOT NULL,
	CONSTRAINT `fk_comments_users` FOREIGN KEY (`user_id`) REFERENCES
	users( `id`) ,
	CONSTRAINT `fk_comments_tales` FOREIGN KEY (`tale_id`) REFERENCES
	tales( `id`)
	) ENGINE = innodb;

That completes the table definition. By this time you will have started to think that
if RoR is so productive, why do we still have to use the SQL statements to create
tables?. There is another way—the Ruby way. We will see that in the next chapter
where we will convert all the table creation statements using Ruby. Now that the
required table has been defined, let us develop the modules starting with the
Login management.

Comments

comments