Class ActionView::Base
In: vendor/rails/actionpack/lib/action_view/base.rb
vendor/rails/actionpack/lib/action_view/helpers/active_record_helper.rb
vendor/rails/actionpack/lib/action_view/helpers/form_helper.rb
Parent: Object

Action View templates can be written in three ways. If the template file has a +.erb+ (or +.rhtml+) extension then it uses a mixture of ERb (included in Ruby) and HTML. If the template file has a +.builder+ (or +.rxml+) extension then Jim Weirich‘s Builder::XmlMarkup library is used. If the template file has a +.rjs+ extension then it will use ActionView::Helpers::PrototypeHelper::JavaScriptGenerator.

ERb

You trigger ERb by using embeddings such as <% %>, <% -%>, and <%= %>. The <%= %> tag set is used when you want output. Consider the following loop for names:

  <b>Names of all the people</b>
  <% for person in @people %>
    Name: <%= person.name %><br/>
  <% end %>

The loop is setup in regular embedding tags <% %> and the name is written using the output embedding tag <%= %>. Note that this is not just a usage suggestion. Regular output functions like print or puts won‘t work with ERb templates. So this would be wrong:

  Hi, Mr. <% puts "Frodo" %>

If you absolutely must write from within a function, you can use the TextHelper#concat

<%- and -%> suppress leading and trailing whitespace, including the trailing newline, and can be used interchangeably with <% and %>.

Using sub templates

Using sub templates allows you to sidestep tedious replication and extract common display structures in shared templates. The classic example is the use of a header and footer (even though the Action Pack-way would be to use Layouts):

  <%= render "shared/header" %>
  Something really specific and terrific
  <%= render "shared/footer" %>

As you see, we use the output embeddings for the render methods. The render call itself will just return a string holding the result of the rendering. The output embedding writes it to the current template.

But you don‘t have to restrict yourself to static includes. Templates can share variables amongst themselves by using instance variables defined using the regular embedding tags. Like this:

  <% @page_title = "A Wonderful Hello" %>
  <%= render "shared/header" %>

Now the header can pick up on the @page_title variable and use it for outputting a title tag:

  <title><%= @page_title %></title>

Passing local variables to sub templates

You can pass local variables to sub templates by using a hash with the variable names as keys and the objects as values:

  <%= render "shared/header", { :headline => "Welcome", :person => person } %>

These can now be accessed in shared/header with:

  Headline: <%= headline %>
  First name: <%= person.first_name %>

If you need to find out whether a certain local variable has been assigned a value in a particular render call, you need to use the following pattern:

  <% if local_assigns.has_key? :headline %>
    Headline: <%= headline %>
  <% end %>

Testing using defined? headline will not work. This is an implementation restriction.

Template caching

By default, Rails will compile each template to a method in order to render it. When you alter a template, Rails will check the file‘s modification time and recompile it.

Builder

Builder templates are a more programmatic alternative to ERb. They are especially useful for generating XML content. An XmlMarkup object named xml is automatically made available to templates with a +.builder+ extension.

Here are some basic examples:

  xml.em("emphasized")                              # => <em>emphasized</em>
  xml.em { xml.b("emph & bold") }                    # => <em><b>emph &amp; bold</b></em>
  xml.a("A Link", "href"=>"http://onestepback.org") # => <a href="http://onestepback.org">A Link</a>
  xml.target("name"=>"compile", "option"=>"fast")   # => <target option="fast" name="compile"\>
                                                    # NOTE: order of attributes is not specified.

Any method with a block will be treated as an XML markup tag with nested markup in the block. For example, the following:

  xml.div {
    xml.h1(@person.name)
    xml.p(@person.bio)
  }

would produce something like:

  <div>
    <h1>David Heinemeier Hansson</h1>
    <p>A product of Danish Design during the Winter of '79...</p>
  </div>

A full-length RSS example actually used on Basecamp:

  xml.rss("version" => "2.0", "xmlns:dc" => "http://purl.org/dc/elements/1.1/") do
    xml.channel do
      xml.title(@feed_title)
      xml.link(@url)
      xml.description "Basecamp: Recent items"
      xml.language "en-us"
      xml.ttl "40"

      for item in @recent_items
        xml.item do
          xml.title(item_title(item))
          xml.description(item_description(item)) if item_description(item)
          xml.pubDate(item_pubDate(item))
          xml.guid(@person.firm.account.url + @recent_items.url(item))
          xml.link(@person.firm.account.url + @recent_items.url(item))

          xml.tag!("dc:creator", item.author_name) if item_has_creator?(item)
        end
      end
    end
  end

More builder documentation can be found at builder.rubyforge.org.

JavaScriptGenerator

JavaScriptGenerator templates end in +.rjs+. Unlike conventional templates which are used to render the results of an action, these templates generate instructions on how to modify an already rendered page. This makes it easy to modify multiple elements on your page in one declarative Ajax response. Actions with these templates are called in the background with Ajax and make updates to the page where the request originated from.

An instance of the JavaScriptGenerator object named page is automatically made available to your template, which is implicitly wrapped in an ActionView::Helpers::PrototypeHelper#update_page block.

When an .rjs action is called with link_to_remote, the generated JavaScript is automatically evaluated. Example:

  link_to_remote :url => {:action => 'delete'}

The subsequently rendered +delete.rjs+ might look like:

  page.replace_html  'sidebar', :partial => 'sidebar'
  page.remove        "person-#{@person.id}"
  page.visual_effect :highlight, 'user-list'

This refreshes the sidebar, removes a person element and highlights the user list.

See the ActionView::Helpers::PrototypeHelper::GeneratorMethods documentation for more details.

Methods

Included Modules

ERB::Util CompiledTemplates Helpers

Attributes

assigns  [RW] 
base_path  [RW] 
controller  [RW] 
first_render  [R] 
headers  [R] 
logger  [R] 
response  [R] 
template_extension  [RW] 
template_format  [W] 
view_paths  [RW] 

Public Class methods

[Source]

     # File vendor/rails/actionpack/lib/action_view/base.rb, line 255
255:     def self.handler_for_extension(extension)
256:       (extension && @@template_handlers[extension.to_sym]) || @@default_template_handlers
257:     end

[Source]

     # File vendor/rails/actionpack/lib/action_view/base.rb, line 250
250:     def self.register_default_template_handler(extension, klass)
251:       register_template_handler(extension, klass)
252:       @@default_template_handlers = klass
253:     end

Register a class that knows how to handle template files with the given extension. This can be used to implement new template types. The constructor for the class must take the ActiveView::Base instance as a parameter, and the class must implement a render method that takes the contents of the template to render as well as the Hash of local assigns available to the template. The render method ought to return the rendered template as a string.

[Source]

     # File vendor/rails/actionpack/lib/action_view/base.rb, line 242
242:     def self.register_template_handler(extension, klass)
243:       @@template_handlers[extension.to_sym] = klass
244:     end

[Source]

     # File vendor/rails/actionpack/lib/action_view/base.rb, line 246
246:     def self.template_handler_extensions
247:       @@template_handler_extensions ||= @@template_handlers.keys.map(&:to_s).sort
248:     end

Public Instance methods

Adds a view_path to the end of the view_paths array. This change affects the current request only.

  @template.append_view_path("views/default")
  @template.append_view_path(["views/default", "views/custom"])

[Source]

     # File vendor/rails/actionpack/lib/action_view/base.rb, line 440
440:     def append_view_path(path)
441:       @view_paths.push(*path)
442:     end

Gets the full template path with base path for the given template_path and extension.

  full_template_path('users/show', 'html.erb')
  # => '~/rails/app/views/users/show.html.erb

[Source]

     # File vendor/rails/actionpack/lib/action_view/base.rb, line 378
378:     def full_template_path(template_path, extension)
379:       if @@cache_template_extensions
380:         (@@cached_base_paths[template_path] ||= {})[extension.to_s] ||= find_full_template_path(template_path, extension)
381:       else
382:         find_full_template_path(template_path, extension)
383:       end
384:     end

Adds a view_path to the front of the view_paths array. This change affects the current request only.

  @template.prepend_view_path("views/default")
  @template.prepend_view_path(["views/default", "views/custom"])

[Source]

     # File vendor/rails/actionpack/lib/action_view/base.rb, line 430
430:     def prepend_view_path(path)
431:       @view_paths.unshift(*path)
432:     end

symbolized version of the :format parameter of the request, or :html by default.

[Source]

     # File vendor/rails/actionpack/lib/action_view/base.rb, line 418
418:     def template_format
419:       return @template_format if @template_format
420:       format = controller && controller.respond_to?(:request) && controller.request.parameters[:format]
421:       @template_format = format.blank? ? :html : format.to_sym
422:     end

[Validate]