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.
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:
<%# WRONG %> Hi, Mr. <% puts "Frodo" %>
If you absolutely must write from within a function use
concat
.
<%- and -%> suppress leading and trailing whitespace, including the trailing newline, and can be used interchangeably with <% and %>.
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>
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.
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 in development mode.
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 & 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 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::JavaScriptGenerator::GeneratorMethods documentation for more details.
# File lib/action_view/base.rb, line 170 def self.debug_rjs=(new_value) ActiveSupport::Deprecation.warn("config.action_view.debug_rjs will be removed in 3.1, from 3.1 onwards you will need to install prototype-rails to continue to use RJS templates ") @@debug_rjs = new_value end
# File lib/action_view/base.rb, line 207 def self.process_view_paths(value) value.is_a?(PathSet) ? value.dup : ActionView::PathSet.new(Array.wrap(value)) end
# File lib/action_view/base.rb, line 237 def controller_path @controller_path ||= controller && controller.controller_path end
TODO: HACK FOR RJS
# File lib/action_view/base.rb, line 199 def view_context self end