Click here to view the complete list of archived articles

This article was originally published in the Fall 2006 issue of Methods & Tools


An Introduction to Web Development Using the Ruby on Rails Framework - Part 4

Nico Mommaerts

The View

Our ride through Rails is almost done, only the View layer is left. It can be found in the ActionView bundle and is the easiest one of the three. The View is comprised of all the rhtml pages found in the 'views' directory, as shown in the Controller examples. There is not much difference between a plain html file and a rhtml file, except that a rhtml file may contain small pieces of embedded Ruby code, called ERb.

Rails defines some helper methods for use on rhtml pages that make it easy to generate links, forms etc in your pages. There is also support for AJAX, that nifty JavaScript technology that lets you make Web pages that behave almost like a rich client. You can create typical AJAX effects, like submitting a form without refreshing the entire page, without even having to write any JavaScript yourself.

There is one other important thing to know about rhtml pages in Rails: it is possible to use a template system, called Layout. It would be really cumbersome if we would have to write each rhtml page beginning with the opening <html> tag until the closing </html> tag, especially given the fact that most pages will probably have a lot of html in common, for example a navigation bar. The template system takes care of this:

<html>

<head>
</head>

<body>
<%= yield %>
</body>

</html>

The '<%= yield %>' line is an example or ERb. The <% %> denotes that we want to execute a piece of Ruby code and <%= %> means we want to render the output of the embedded Ruby code on the html page. The 'yield' method returns the content of the currently rendered page. This very simple example layout dismisses the need to write the boilerplate html every page. A page may look like this:

<h1>no need to write surrounding html tags</h1>

The final rendered page would have an html source like this:

<html>

<head>
</head>

<body<
<h1>no need to write surrounding html tags</h1>
</body>

</html>

How does Rails know which template to apply, if any? Again, it looks in certain directories and expects certain filenames. Continuing on the previous file layout, it could look like this:

/app

/controllers
employees_controller.rb

/models
employee.rb

/views

/employees
show.rhtml

/layouts
application.rhtml
employees.rhtml

The default directory for storing layouts is in views/layouts. When rendering a view, for example the employees/show.rhtml view, Rails will look in the layouts folder and search for a file with the same name as the controller that renders the view, 'employees.rhtml' in this case. If the employees.rhtml file contains a line <%= yield %>, it will be replaced with the contents of the employees/show.rhtml file.

You might also notice another (optional) file in the layouts directory, the 'application.rhtml' file. This is a special template, as it will be used as the default template for each controller unless explicitly overridden.

Summary

If you are already familiar with Web frameworks that use the MVC pattern, you might have noticed that Rails isn't anything revolutionary. Rails' strength is rather in the synergy between its various parts, ActiveRecord, ActionPack, ActionMailer and ActionWebService. I have not touched the last two modules but they are not as important as the former two. By fully utilizing the dynamic power of Ruby and using conventions instead of tedious configuration files, Rails became one the most beloved Web frameworks of the last years. Since it is so beloved by some, and loathed by others, discussions about it often become very emotional and its hard to know what to believe or not. Is it a framework that will solve all our problems and make all other Web frameworks obsolete? Or is it only suited to build small Web applications, nothing up to the challenges found in the 'Enterprise' world? The correct answer is none of the two. Rails is a solution for a certain range of problems and it is the responsibility of the developer to choose the appropriate tools for the job.

Links

Page 3   Back to the archive list