Vou utilizar o exemplo que eu tenho aqui, onde eu fiz o scaffold* para o modelo "reading".
Na view index.html.erb foi gerado o seguinte trecho de código:

[sourcecode language='ruby']
#index.html.erb

<% for reading in @readings %>

<% end %>
[/sourcecode]
Eu gostaria de reutilizar o trecho que está exibindo cada "reading", então, eu vou retirar e colocar este trecho de código em uma Partial, assim eu posso chamá-la em qualquer outro lugar da minha aplicação, onde eu queira exibir as informações da mesma maneira.

Uma partial é um arquivo que começa com um "_", underscore, underline.... então vou criar um arquivo _reading.html.erb (dentro da pasta de views de readings), e vou pegar todo o código que estava dentro do meu for. Este será o conteúdo da partial:
#_reading.html.erb
[sourcecode language='ruby']

[/sourcecode]

E finalmente vou alterar o meu index.html.erb, substituindo:

[sourcecode language='ruby']
#index.html.erb

[/sourcecode]

Por uma única linha:

[sourcecode language='ruby']
#index.html.erb

<%= render :partial => 'reading', :collection => @readings%>
[/sourcecode]

A partial receberá a collection "readings" como parâmetro.

Simples, bonito, e limpo!

Newbies Corner:
Scaffold é uma operação do Rails onde vc passa um nome de modelo e os campos, e ele gera uma aplicação CRUD (Create, Retrieve, Update e Delete) completa.
Ex: o comando "script/generate scaffold person name:string tel:number" vai gerar um cadastro completo de pessoas com nome e telefone, permitindo listar, excluir e alterar cada registro.

Also received an editor request for a partial.

Remember: The Hives' The Black and White Album is released tomorrow (Saturday). Be good and go buy it - I know I will! ;-)

Downloads:
10 page pdf article only, or article and sample code.

So, you've read “Agile Web Development with Rails”, and you've started to tinker with some pages on your own, but you just can't figure out how you're supposed to use that view file to create your 3 column layout? So far I’ve found every tutorial on Rails talks about the default chain of controller to view to layout and stops. 3 files, done. Well, then what?

I felt your pain. So, I've prepared an article and sample code set (links up top) intended to pick up where AWDWR leaves off in explaining how to organize files for a modular page assemby approach with layouts and partials.

If you’ve come from a template-driven web application framework, the way Rails builds pages can feel a bit backwards. For me, I was accustomed to the exact opposite fo how Rails works. I'm used to the layout being the starting point, and its structure determining which view fragments the framework would include (based on dynamic file name conventions).

By the time I get to writing code for a site I have a pretty solid idea of how it will look, and how it needs to be structured. While AWDWR is a good intro, it left me feeling like I still had no idea how I was going to build typical modular web pages using layouts with reusable panels. Only after I figured this out was my brain going to feel free to work on the logical side of Rails.

So, I focused on solving that puzzle before I went much further. Out of that process, you get my first blog, and my first article about Rails. (I've written quite a bit about another language called Lasso).

I'll use your feedback to shape the article's updates. If you think I should address some particular idioms, let me know. My objective is to provide material that's more complete than the gloss-overs we usually get treated to in web articles.

Oct 22 Update: I have expanded the article to include the passing of data into the various display components. Indeed, solving this task to meet several goals required that I change how I was doing some things in the first version of the article.

<% # Parameters: upload_path, unique_name,
   #         title = nil, other = nil %>

This outputs the <%= upload_path %>

<% if title then %>
  Output the title <%= title %> only if there was one.
<% end %>

The problem with this is that every time you call the partial, you have to send in nils for the optional locals regardless (e.g. :title => nil, :other => nil) with your render call, as shown below

<%= render :partial => 'shared/my_partial',
    :locals => {
        :upload_path => 'dumdeedum',
        :unique_name => "slideshow",
        :title => nil,
        :other => nil
    } %>

Knowing this wasn't particularly elegant, I wanted a better solution. Here's how you make the title and other local variable optional.

UPDATE: for a reason I still don't understand, unless defined?(x) doesn't always perform as you'd expect in a partial. I've switched to using local_assigns[:x].nil? (.nil? to get around if x == false). This solution currently doesn't seem work with HAML, but works like a charm in RHTML.

<%
  # Parameters: upload_path, unique_name, title = nil, other = nil
  title = nil unless defined?(title)
  other = nil unless defined?(other)

  title = nil if local_assigns[:title].nil?
  other = nil if local_assigns[:other].nil?
%>

This outputs the <%= upload_path %>

<% if title then %>
  Output the title <%= title %> only if there was one.
<% end %>

Now you can call it and leave off the optional parameters as you please!

<%= render :partial => 'shared/my_partial',
    :locals => {
        :upload_path => 'dumdeedum',
        :unique_name => "slideshow"
    } %>

Well, I hope this make your code DRY as it's helped make ours!

Um dos princípios do symfony é o DRY (Don't Repeat Yourself ou "Não se repita"). Para nos ajudar com esta tarefa, o framework disponibiliza quatro helpers que podem ser utilizados conforme a necessidade.

Esta segunda cheat-sheet sobre a camada de visão (View) do symfony, trata justamente destes helpers para trabalhar com:

• Partials: include_partial()
• Components: include_component()
• Slots: include_slot()
• Component Slots: include_component_slot()

Idiomas disponíveis:

• English - PDF
• Português - em breve