1.6. Building a View

You now have a controller that renders text, but this design can take you only so far. If you want to follow Rails MVC conventions, you should render text in a separate view instead of a controller. The sloppy design is easy enough to fix. Instead of printing raw text in a controller, render it in a view. As with many web frameworks, Rails can use a template strategy for the view. For Rails, a template is simply an HTML page with Ruby code mixed in. The Ruby code executes on the server, adding dynamic content to the HTML page.

Documentation Unlike many open source projects, Rails has excellent documentation. You can find it all at http://api.rubyonrails.com. You'll find overviews, tutorials, and even movies. You can always find the API document for the latest version of Ruby on Rails at the site, with a full set of documents for every class in the Rails API. You can also find it with your Rails installation. The excellent Rails documentation is not an accident. Like Java, Ruby comes with a utility called RubyDoc that generates documentation from source code and comments that you provide within the source code. When you install a gem, it also installs the documentation for the gem. "#rubyrails-chp-1-fig-4">Figure 1-4 shows the documentation for a controller. Figure 1-4. Rails documentation for the controller

With Rails, you can generate the view and some helpers that the view will need. Type the generate command to generate a new controller, greeting, with a view, index. (You do this to tie the view and controller together.) When it asks you whether to overwrite the controller, type n for no:

    > ruby script/generate controller Greeting index
      exists  app/controllers/

      exists  app/helpers/
      exists  app/views/greeting
      exists  test/functional/
overwrite app/controllers/greeting_controller.rb? [Ynaq] n
        skip  app/controllers/greeting_controller.rb
overwrite test/functional/greeting_controller_test.rb? [Ynaq] a
forcing controller
       force  test/functional/greeting_controller_test.rb
       force  app/helpers/greeting_helper.rb
      create  app/views/greeting/index.rhtml

The generator created the view, index.rhtml, with helper and test files. Keep the index method, so Action Pack can find the action, but take the rest of the code out of the index method:

class GreetingController < ApplicationController
   def index
   end
end

Unlike most MVC frameworks, you didn't specify a view. If your controller doesn't render anything, Rails uses naming conventions to find the right view. The controller's name determines the view's directory, and the controller's method name determines the name of the view. In this case, Action Pack fires the view in app/view/greeting/index.rhtml. You didn't have to edit any XML files or type any additional code. You provide consistent naming conventions, and Rails infers your intent.

Now, edit the view. You'll find this data:

<h1>Greeting#index</h1>
<p>Find me in app/views/greeting/index.rhtml</p>

Reload your browser to see the previous message in HTML. Rails tells you where to find the file, should you ever render an unimplemented view. Rails is full of nice finishing touches like these.