Fernando Luizão

Relato passo a passo das alteraçoẽs para migrar o Brazilian Rails:

Adicionados comentários de encoding. commit commit

: (dois pontos) não são mais válidos como separador de instruções. Deve-se trocar por ; ou then, ambas funcionam no 1.8 e 1.9. commit

ParseDate foi removido, Date#parse faz grande parte do que fazia o ParseDate. commit

O 1.9 introduziu o método Numeric#real, e estava sobrescrevendo um alias. commit

Variável $KCODE não tem mais efeito no 1.9, será setada apenas se a versão for anterior a 1.9. commit

A parte mais chata foi relacionada ao parser datas. O Date#parse no 1.9 se comporta de maneira diferente do 1.8, foram introduzidos outros formatos para parseamento, e o parse tenta converter a data com os novos formatos. Exemplo do novo comportamento:

# ruby 1.8.7
Date.parse("13/12/200A")
ArgumentError: invalid date
    from /usr/lib/ruby/1.8/date.rb:956:in `new_by_frags'
    from /usr/lib/ruby/1.8/date.rb:1000:in `parse'
    from (irb):7
    from /usr/lib/ruby/1.8/date.rb:811

# ruby 1.9.1
Date.parse("13/12/200A")
=> #<date: 0200-12-13>

Outra mudança foi que o formato padrão do parse passou a ser dd/mm/yyyy em vez de mm/dd/yyyy:

# ruby 1.8.7
Date.parse("10/12/2009")
=> Seg, 12 Out 2009

# ruby 1.9.1
Date.parse("10/12/2009")
=> Qui, 10 Dez 2009

Levando em conta essas mudanças, alterei o formado de algumas datas nesse teste. Esse outro teste, não está sendo executado no 1.9, justamente pelas diferenças do parse.

Sim, sei que essa solução está longe da ideal, mas para manter o mesmo comportamento seria necessário sobrescrever o parser do 1.9, e não gosto dessa solução… Para quem usa apenas datas no formato brasileiro, não vejo problemas, o Date#valid? continua funcionando (afinal, o propósito da brdata é trabalhar com datas no formato brasileiro ). O problema é se forem usadas datas em outros formatos, pois aí quem se encarrega de fazer a conversão é o parser do Ruby. Então, se você escolheu usar uby 1.9, esteja ciente das mudanças na classe Date.

Talvez no futuro seja interessante repensar a forma como o método Date#valid? é implementado, mas por hora, creio que deixar a cargo do usuário é razoável, já que é dele a decisão e sobre qual versão do Ruby usar. O suporte da brdata no 1.9 ainda é experimental, então se algém tiver idéias melhores, se pronuncie =).

Finalizando, destaco o papel dos testes na migração. Por sorte o Brazilian Rails tem uma boa cobertura, o que facilitou bastante. A cada alteração feita eu rodava os testes no 1.9 e no 1.8 para ver se estava tudo certo .

PS: para mudar a versão do Ruby eu uso o ruby_switcher. Também tem o rvm, mas acho o ruby_switcher mais simples.

O Ruby 1.9 agora leva em consideração o encoding das strings nos arquivos, então caso algum arquivo ruby tenha algum caracter não ASCII (caracteres acentuados por exemplo), será exibido o erro:

invalid multibyte char (US-ASCII)

Para que o erro não ocorra, basta adicionar o comentário abaixo na primeira linha do arquivo *.rb:

# encoding: UTF-8

Ao migrar um projeto Rails para Ruby 1.9, esse erro acontecia em vários arquivos, então nada melhor que deixar o computador resolver o problema por você . O comando abaixo vai colocar esse comentário em todos os controllers, helpers e models do seu projeto Rails:

cd seu_projeto
find app/{controllers,models,helpers} -type f -name \*.rb | xargs sed -i '1i # encoding: UTF-8'

Para quem usa windows, pode usar o seguinte script Ruby para fazer o mesmo:

# utf_comment.rb
Dir["app/{controllers,models,helpers}/**/*.rb"].each do |filename|
  content = File.read(filename).sub(/^/, "# encoding: UTF-8\n")
  File.open(filename, "r+") { |f| f.write(content) }
end

Execute com

cd seu_projeto
ruby utf_comment.rb

Para mais informações sobre codificação de strings, aqui tem vários artigos abordando as mudanças. Recomendo a leitura!

NOTA: se vc não faz idéia do que é STI, veja esse link.

Não dá pra negar que STI (Single Table Inheritance) é um recurso bacana do Rails. Claro que não é bom abusar, mas em alguns casos, ela se encaixa muito bem. No rails, quando queremos usar STI, basta ter uma coluna type do tipo string na tabela “mãe”, e nessa coluna o Rails se encarrega de gravar o nome da classe do registro, e a partir daí tudo funciona normalmente (para mais detalhes sobre como funciona STI no Rails, veja a api). Porém, apesar da implementação do Rails ser muito elegante e funcionar bem, ela tem alguns problemas:

• Comparações entre strings são lentas. Mesmo que haja um índice na coluna “type”, comparações entre strings ainda são bem mais lentas que comparações entre inteiros.
• Caso o model seja renomeado, os dados da coluna “type” terão que ser atualizados, ou ficaremos com dados incorretos na tabela. Para corrigir podemos criar uma migration, mas é mais uma coisa para se preocupar

Vamos tentar melhorar isso!

Criando um projetinho de exemplo (NOTA: estou usando Rails 2.3.3. Se usa uma versão mais antiga, veja algumas considerações mais abaixo):

rails sti
cd sti
script/generate model pessoa nome:string documento:string tipo:integer

Estamos criando nossa tabela base, e em vez de usar uma coluna type do tipo string, vamos usar uma coluna chamada tipo (o nome da coluna poderia ser qualquer um), do tipo inteiro.

Vamos editar nossa migração e adicionar um índice na migration para melhorar a performance nas buscas:

class CreatePessoas < ActiveRecord::Migration
  def self.up
    create_table :pessoas do |t|
      t.string :nome
      t.string :documento
      t.integer :tipo
      t.timestamps
    end

    #adicionando o indice
    add_index :pessoas, [:id, :tipo]
  end

  def self.down
    drop_table :pessoas
  end
end

Criando o banco e nossa tabela de testes:

rake db:create
rake db:migrate

Alterando o model Pessoa para adicionar algumas constantes com os tipos de pessoas:

#app/models/pessoa.rb
class Pessoa < ActiveRecord::Base
  # tipos de pessoa
  JURIDICA = 1
  FISICA   = 2
end

Agora, vamos criar dois models que herdam de Pessoa, PessoaFisica e PessoaJuridica, e definir os seus default_scopes:

#app/models/pessoa_fisica.rb
class PessoaFisica < Pessoa
  default_scope :conditions => {:tipo => FISICA}
end

#app/models/pessoa_juridica.rb
class PessoaJuridica < Pessoa
  default_scope :conditions => {:tipo => JURIDICA}
end

Só isso? Só . Aparentemente, o Rails está bem espertinho, e quando instânciamos um objeto ele já se encarrega de colocar o valor correto na coluna tipo, da mesma forma que STI faz:

Pessoa.new
#<Pessoa id: nil, nome: nil, documento: nil, tipo: nil>
PessoaJuridica.new
#<PessoaJuridica id: nil, nome: nil, documento: nil, tipo: 1>
PessoaFisica.new
#<PessoaFisica id: nil, nome: nil, documento: nil, tipo: 2>

Criando algumas pessoas:

Pessoa.create(:nome => "Pessoa indefinida")
PessoaFisica.create(:nome => "João da Silva", :documento => "123.456.789-10")
PessoaFisica.create(:nome => "José Oliveira", :documento => "000.111.222-33")
PessoaJuridica.create(:nome => "Padaria pão quentinho", :documento => "26.721.163/0001-52")
PessoaJuridica.create(:nome => "Transportadora Leva e Traz", :documento => "70.562.197/0001-31")

Buscando:

>> Pessoa.all
# SELECT * FROM "pessoas"
=> [#<Pessoa id: 1, nome: "Pessoa indefinida", documento: nil, tipo: nil, created_at: "2009-08-12 01:08:29", updated_at: "2009-08-12 01:08:29">, #<Pessoa id: 2, nome: "João da Silva", documento: "123.456.789-10", tipo: 2, created_at: "2009-08-12 01:08:29", updated_at: "2009-08-12 01:08:29">, #<Pessoa id: 3, nome: "José Oliveira", documento: "000.111.222-33", tipo: 2, created_at: "2009-08-12 01:08:29", updated_at: "2009-08-12 01:08:29">, #<Pessoa id: 4, nome: "Padaria pão quentinho", documento: "26.721.163/0001-52", tipo: 1, created_at: "2009-08-12 01:08:29", updated_at: "2009-08-12 01:08:29">, #<Pessoa id: 5, nome: "Transportadora Leva e Traz", documento: "70.562.197/0001-31", tipo: 1, created_at: "2009-08-12 01:08:29", updated_at: "2009-08-12 01:08:29">]

>> PessoaJuridica.all
# SELECT * FROM "pessoas" WHERE ("pessoas"."tipo" = 1)
=> [#<PessoaJuridica id: 4, nome: "Padaria pão quentinho", documento: "26.721.163/0001-52", tipo: 1, created_at: "2009-08-12 01:08:29", updated_at: "2009-08-12 01:08:29">, #<PessoaJuridica id: 5, nome: "Transportadora Leva e Traz", documento: "70.562.197/0001-31", tipo: 1, created_at: "2009-08-12 01:08:29", updated_at: "2009-08-12 01:08:29">]

>> PessoaFisica.all
# SELECT * FROM "pessoas" WHERE ("pessoas"."tipo" = 2)
=> [#<PessoaFisica id: 2, nome: "João da Silva", documento: "123.456.789-10", tipo: 2, created_at: "2009-08-12 01:08:29", updated_at: "2009-08-12 01:08:29">, #<PessoaFisica id: 3, nome: "José Oliveira", documento: "000.111.222-33", tipo: 2, created_at: "2009-08-12 01:08:29", updated_at: "2009-08-12 01:08:29">]

Para quem ainda usa uma versão do Rails menor que 2.3 e maior que 2.0, uma solução é instalar o plugin com o backport do default_scope:

script/plugin install git://github.com/duncanbeevers/default_scope.git

Além disso, será necessário usar uma callback para setar a coluna tipo com o valor correto. Por exemplo:

class PessoaFisica < Pessoa
  default_scope :conditions => {:tipo => FISICA}
  before_save { |p| p.tipo = FISICA }
end

Para quem usa uma versão do mais antiga que a 2, já passou da hora de atualizar hem .

Finalizando

Conseguimos o mesmo comportamento da STI, sem as desvantagens citadas anteriormente, usando apenas algumas linhas de código a mais (os default_scopes e as constantes que definimos, no total 4 linhas). Espero que essa dica seja útil, e lembre-se, aprecie STI com moderação .

NOTA: Antes de começar, se você não sabe o que é ou não tem uma noção básica sobre o i18n do Rails, leia esse guia.

Fazer conversões de datas e números localizados sempre foi uma tarefa chata em Rails (e em outras linguagens/frameworks também). O usuário digita uma data no formato brasileiro (por exemplo, dd/mm/yyyy), e o Ruby não consegue converter a data corretamente. A maneira mais usada por aí é criar atributos virtuais (ou mesmo sobrecrever o setter padrão do atributo) no model para fazer a conversão, por exemplo:

class Model < ActiveRecord::Base

  #recebe uma data no formato dd/mm/yyyy e converte para yyyy-mm-dd
  def data_vencimento=value
    self[:data_vencimento] = value.split("/").reverse.join("-")
  end

end

Isso funciona, mas quando eu usava isso não ficava satisfeito, queria algo mais “mágico” . Perguntei no fórum RubyOnBr se não teria um jeito de fazer a conversão automaticamente, usando o próprio i18n do Rails. Então meu camarada Rafael Rosa chegou a uma solução, usando o formato padrão de data configurado no aquivo de i18n para fazer o parsing de datas. Eu acrescentei suporte à números, o Rafael organizou tudo, escreveu testes, e surgiu o i18n_localize_core.
O plugin funciona bem, consegue converter datas e números usando as configurações do arquivo de internacionalização. O plugin resolvia bem para mim, inclusive tinha feito alguns hacks no plugin para fazer a conversão nos text_fields, mas não coloquei no meu fork porque estava muito feio .
Só que a um tempo atrás, encontrei o plugin delocalize, escrito por Clemens Kofler, que faz basicamente a mesma coisa, mas melhor . O i18n_localize_core é meio invasivo, sobrescreve os métodos Date#_parse, String#to_i e String#to_f. No delocalize, o Clemens sobrescreveu apenas onde era necessário, e ainda adicionou suporte à entrada de vários formatos de datas.
Usar o plugin é simples, como tudo na vida deve ser . Tendo configurado seu arquivo de i18n e instalado o plugin, basta adicionar a chave :input no arquivo de i18n com os formatos de data que o usuário poderá digitar e sair pro abraço . O plugin se encarrega de fazer o resto de forma transparente.

No README do plugin tem alguns exemplos de uso, dêem uma conferida no projeto:

http://github.com/clemens/delocalize

Pra quem é do mundo Rails, o acts_as_paranoid já é velho conhecido, ele sobrescreve alguns métodos do ActiveRecord para marcar um registro como excluído em vez de efetivamente excluí-lo. Ele também adiciona um escopo para esconder os registros “exluídos” dos finders e outras operações comuns como count, sum, max, etc. Meu novo plugin, acts_as_active, faz basicamente a mesma coisa, porém utiliza um booleano em vez de um timestamp para indicar que o registro está ativo e utiliza um escopo padrão para mostrar apenas os ativos.

Instalando o acts_as_active

Pra instalar, o de sempre:

script/plugin install git://github.com/fernandoluizao/acts_as_active.git

IMPORTANTE: Meu plugin depende de um novo recurso adicionado no Rails 2.3 chamado default_scope
Para quem usa Rails 2.1 ou 2.2, instale o plugin default_scope.

script/plugin install git://github.com/duncanbeevers/default_scope.git

Uso

O plugin assume que vc tem um campo booleano com o nome “active”, com valor default TRUE. Exemplo de uso:

  create_table :users do |t|
    t.string :name
    t.string :last_name
    t.boolean :active, :null => false, :default => true
  end

  class User < ActiveRecord::Base
    acts_as_active
  end

  User.first.destroy
  UPDATE users SET active = 'f' WHERE id = 1

  #chama o destroy original e acaba com nosso usuário
  User.first.destroy! 
  DELETE FROM users WHERE id = 1

  User.all
  SELECT * FROM users WHERE active = 't'

  User.all :conditions => {:name => "joe"}
  SELECT * FROM users WHERE (name = 'joe') AND (active = 't')

Se quiser procurar incluindo os inativos:

  User.find_with_inactive :conditions => {:name => "joe"}
  SELECT * FROM users WHERE (name = 'joe')

O nome do campo booleano pode ser configurado da seguinte forma:

class User < ActiveRecord::Base
  acts_as_active :with => :nome_campo
end

É isso, um plugin simples, mas que me poupa um bom trabalho. Espero que gostem .

Consultas case insensitive e independentes de acentos que funcionem em qualquer SGBD são difíceis de conseguir, pois cada banco possui sua maneira específica de fazer isso. Se forem tomados alguns cuidados, é possível usar a sintaxe correta de acordo com o adaptador que estamos usando. No PostgreSQL por exemplo, para conseguir uma consulta case insensitive e independente de acentos, temos que fazer coisas assim ou assim.

O problema em usar conversões nas colunas é que, além delas não fazerem parte padrão SQL, perdemos os índices na coluna, o que vai fazer nossa consulta demorar um pouco mais (dependendo da quatidade de registros, usar ou não um índice pode fazer uma grande diferença). Para resolver esse problema, criei o plugin “Insensitivity“, que usa uma coluna extra para armazenar o valor sem acentos e em minúsculas. Assim, durante as consultas, o ActiveRecord irá utilizar essa coluna em vez da coluna com o valor real.

Vantagens dessa abordagem

Independente de banco
Se hover índices, serão usados

Desvantagens

Utiliza o dobro de espaço.

Instalando e usando o plugin

script/plugin install git://github.com/fernandoluizao/insensitivity.git

No seu model, você deve indicar quais campos usarão a pesquisa case insensitive:

class User < ActiveRecord:Base
  insensible :name, :email
end

Depois, você DEVE adicionar à tabela, os campos com o mesmo nome dos que foram indicados e com o sufixo “_search”. Se desejar, também coloque índices para melhorar a performance. Por exemplo:

script/generate migration add_search_fields

def self.up
  change_table :users do |t|
    t.string :name_search
    t.string :email_search
  end

  add_index :users, :name_search
  add_index :users, :email_search

  #Se sua tabela ja tiver dados, vc pode usar
  #User.make_insensible!
  #Isso vai inicializar os novos campos nos registros já existentes
end

def self.down
  change_table :users do |t|
    t.remove :name_search
    t.remove :email_search
  end
end

Para fazer as buscas, não muda nada. Veja as consultas geradas:

User.find_by_name('bla')
SELECT * FROM users WHERE name_search = 'bla'

User.find(:first, :conditions => ['name = ?', 'bla'], :order => 'name')
SELECT * FROM users WHERE name_search = 'bla' ORDER BY name LIMIT 1

Tudo funciona de forma transparente, sem vc precisar se preocupar =). Sua única preocupação deve ser passar o valor nas conditions sem acentos e em minusculas, para isso pode usar o método “insensible”, adicionado à classe String:

User.find(:first, :conditions => ['name LIKE ?', "%#{params[:name].insensible}%"])
SELECT * FROM users WHERE name_search LIKE '%bla%'

Bom, é isso, pesquisa sem sentimentos . Quem quiser colaborar:

http://github.com/fernandoluizao/insensitivity/

PS: Testei apenas com rails 2.2.2. Pode não funcionar com versões mais antigas (< 2.0)

Muita gente tem reclamado que o padrão RESTful do Rails é ruim, que limita, dificulta, etc. Eu não concordo, acho que limitações nos forçam a pensar em soluções mais simples. Realmente, manter-se RESTful não é tão simples quanto sair criando um monte de actions para qualquer coisa, principalmente nos casos de uso de ajax. Uma das reclamações que eu ouvi foi sobre dificuldade em usar autocompletes, por isso nesse artigo vamos ver como resolver esse “problema” e fazer um auto complete RESTful de forma simples e elegante.

Vamos lá, criando o projeto para teste e um resource Pessoa

rails restful_autocomplete
cd restful_autocomplete
script/generate scaffold pessoa nome:string
rake db:migrate

Instalando o plugin auto_complete:

script/plugin install git://github.com/rails/auto_complete.git

É necessário ter o git instalado, caso vc não tenha, ou não esteja com vontade de instalar, baixe o plugin aqui e descompacte em vendor/plugins.

Esse plugin possui uma macro para gerar a action de resposta do auto complete, mas como estamos usando um controller RESTful, não vamos usá-lo dessa maneira. Em vez disso, vamos criar uma mini-API para lidar com o problema. A idéia central é que TODAS as requisições que necessitem recuperar uma coleção de pessoas usem como ÚNICO ponto de acesso a action index.

O plugin espera os registros formatados dentro de uma lista não ordenada, por exemplo:

<ul>
	<li>Item 1</li>
	<li>Item 2</li>
        ...
	<li>Item N</li>
</ul>

Com isso em mente, vamos criar um novo mime-type para que nosso controller se encarregue de identificar a requisição do auto complete e devolver o formato correto. Adicione a seguinte linha ao arquivo config/initializers/mime_types.rb:

Mime::Type.register_alias "text/html", :autocomplete

Estamos registrando o tipo customizado “autocomplete” como HTML. Lembre-se de reiniciar o servidor depois de alterar o arquivo.

Agora criaremos um controller qualquer que fará a requisição pelo auto complete:

script/generate controller testes new

Na view testes/new.html.erb, coloque o seguinte:

<%=
    text_field_with_auto_complete :bla, :ble, { :size => 25 }, {
      :url => formatted_pessoas_path(:autocomplete),
      :method => :get,
      :param_name => 'nome'
    }
%>

Passamos algumas opções ao helper text_field_with_auto_complete fornecido pelo plugin:

• Na linha 3 indicamos a url (ou melhor, o RECURSO) à qual a requisição será ser feita e o mime-type que desejamos (o “autocomplete” que nós criamos). A url gerada será /pessoas.autocomplete
• Na linha 4 estamos dizendo que queremos que a requisição seja feita pelo método GET (LEMBRE-SE: A action index só é acessivel por GET em um controller RESTful)
• Finalmente na linha 5 especificamos com qual nome o conteúdo do text_field será enviado. O valor do parâmetro depois poderá ser acessado com params[:nome].

A action index do controller pessoas (nossa “API”), responsável pelo trabalho sujo, ficará assim:

def index
  conditions = ["nome LIKE ?", "%#{params[:nome]}%"] if params[:nome]
  @pessoas = Pessoa.all :conditions => conditions

  respond_to do |format|
    format.html # index.html.erb
    format.xml  { render :xml => @pessoas }
    format.autocomplete  { render :inline => "<%= auto_complete_result @pessoas, :nome %>" }
  end
end

A idéia básica de uma API, é que ela receba parâmetros, processe-os, e devolva um resultado. Nossa API é extremamente simples, se receber um parâmetro “nome”, faz a pesquisa pelos nomes que forem similares, senão retorna todos os registros. Podemos incrementar nossa API e adicionar várias outras coisas, como mais opções para pesquisa (pesquisa por idade, por CPF…), limite de registros a serem retornados, paginação, e o que mais for preciso. Essa é a maior vantagem do padrão RESTful, em vez de uma action, você ganha uma API .

A linha 7 é que faz a mágica de responder ao auto complete. Ela devolve os resultados da pesquisa no formato que o auto complete espera, na forma de lista não ordenada, usando o helper auto_complete_result.

Inicie o servidor, e acesse a url http://localhost:3000/testes/new e teste o auto complete.

Pronto, temos um auto complete RESTful! =)

Lembre-se, o modelo RESTful veio para facilitar nossa vida, não para complicar. RESTful restringe visando simplificar o design de nossas aplicações e nos forçar a construir APIs que nós mesmos consumimos (e obviamente, também ser consumidas por terceiros). Limitações são impostas apenas por nós mesmos, por isso, pare de se limitar .

NOTA 1: Não esqueça de incluir os javascripts necessários no seu layout, senão não vai funcionar:

<%= javascript_include_tag :defaults %>

NOTA 2: Os helpers de rotas formatados serão removidos nas próximas versões do Rails. Em vez de:

formatted_pessoas_path(:autocomplete)

Ficará:

pessoas_path(:format => :autocomplete)

Então atenção à versão do Rails que vc está usando. Mais detalhes aqui.

A um ano atrás, o Urubatan escreveu um artigo sobre como diminuir a repetição nas views e padronizar formulários. A abordagem dele foi escrever helpers para encapsular o formulário dentro de uma tabela (não vou entrar no mérito do uso de tabelas para formatação, não sou xiita ). Se você não leu o artigo dele, recomendo que leia. Vou revisitar o artigo dele e apresentar um recurso do Rails que muita gente desconhece (ou ignora): FormBuilders.

O que é um FormBuilder?

Como o nome sugere, um FormBuilder é uma classe para auxiliar a construção de formulários. É essa classe que nos oferece vários métodos que usamos diariamente em nossas views, como text_field, check_box, e vários outros. A maioria das pessoas usa esses métodos sem saber de onde eles vem. Para entender melhor a estrutura do form builder padrão do Rails, recomendo a leitura desse artigo.

Criando nosso FormBuilder

Para criarmos um builder personalizado, temos duas alternativas: implementar os métodos da classe ActionView::Helpers::FormBuilder OU estender essa classe. A segunda é obviamente mais fácil e rápida, e para atingirmos nosso objetivo vamos usá-la. Queremos que nosso FormBuilder nos permita trocar isso (retirado do exemplo do Urubatan):

<% form_for(@example) do |f| %>
  <table>
    <tr>
      <td>Name</td>
      <td><%= f.text_field :name %></td>
    </tr>
    <tr>
      <td>Url</td>
      <td><%= f.text_field :url %></td>
    </tr>
    <tr>
      <td colspan="2"><%= f.submit "Update" %></td>
    </tr>
</table>
<% end %>

Por isso:

<% form_for(@example) do |f| %>
  <%= f.text_field :name %>
  <%= f.text_field :url %>
  <%= f.submit "Update" %>
<% end %>

Vamos ao trabalho!

class MyFormBuilder < ActionView::Helpers::FormBuilder

  # vamos embulhar esses helpers em uma tr
  %w[text_field password_field text_area].each do |method_name|
    define_method(method_name) do |field_name, *args|
      options = args.extract_options!

      # cria o label dentro de uma td
      label = @template.content_tag(:td, label(field_name, options[:label] || field_name.to_s.humanize))

      # cria o elemento dentro de uma td
      input = @template.content_tag(:td, super)

      # cria uma tr com o label e o input criados
      @template.content_tag(:tr, label + input)
    end
  end

  def submit(value = "Save changes", options = {})
    button = @template.content_tag(:td, super, :colspan => 2)
    @template.content_tag(:tr, button)
  end

end

Essa classe pode ser colocada em um arquivo dentro do diretório lib e requerida no environment. Implementei apenas alguns helpers apenas para demonstração, mas outros helpers (check_box, select, etc) também podem ser personalizados a gosto. Agora podemos testar a renderização do formulário usando nosso builder:

<% form_for(@example, :builder => MyFormBuilder) do |f| %>
  <%= f.text_field :name %>
  <%= f.text_field :url %>
  <%= f.submit "Update" %>
<% end %>

Humm, nada de diferente… olhando o html gerado podemos ver que esta correto, os campos estão dentro de tr’s, porém não estão dentro de uma tabela. Vamos sobrescrever o helper form_for para conseguir isso:

module ActionView
  module Helpers
    module FormHelper

      def form_for(record_or_name_or_array, *args, &proc)
        raise ArgumentError, "Missing block" unless block_given?

        options = args.extract_options!

        case record_or_name_or_array
        when String, Symbol
          object_name = record_or_name_or_array
        when Array
          object = record_or_name_or_array.last
          object_name = ActionController::RecordIdentifier.singular_class_name(object)
          apply_form_for_options!(record_or_name_or_array, options)
          args.unshift object
        else
          object = record_or_name_or_array
          object_name = ActionController::RecordIdentifier.singular_class_name(object)
          apply_form_for_options!([object], options)
          args.unshift object
        end

        concat(form_tag(options.delete(:url) || {}, options.delete(:html) || {}))
        concat('<table>')
        fields_for(object_name, *(args << options), &proc)
        concat('</table>')
        concat('</form>')
      end

    end
  end
end

Monkey patching não é a melhor coisa do mundo, mas nesse caso não vi outra solução melhor e achei válido usar. No artigo do Urubatan ele adicionou as tags “table” dentro do próprio formulário. Se tivesse que alterar a marcação no futuro, teria que ser alterado em vários formulários para tirar as tags table. O monkey patch introduz risco de quebrar o sistema em caso de mudanças no Rails, mas acho que vale mais a pena alterar apenas um arquivo do que um monte de formulários .

Testando novamente… funcionou . Muito bom, agora vamos criar um plugin para reusar esse form builder em outros projetos:

script/generate plugin my_builder
      create  vendor/plugins/my_builder/lib
      create  vendor/plugins/my_builder/tasks
      create  vendor/plugins/my_builder/test
      create  vendor/plugins/my_builder/README
      create  vendor/plugins/my_builder/MIT-LICENSE
      create  vendor/plugins/my_builder/Rakefile
      create  vendor/plugins/my_builder/init.rb
      create  vendor/plugins/my_builder/install.rb
      create  vendor/plugins/my_builder/uninstall.rb
      create  vendor/plugins/my_builder/lib/my_builder.rb
      create  vendor/plugins/my_builder/tasks/my_builder_tasks.rake
      create  vendor/plugins/my_builder/test/my_builder_test.rb
      create  vendor/plugins/my_builder/test/test_helper.rb

No arquivo vendor/plugins/my_builder/lib/my_builder.rb coloque o a nossa classe MyFormBuilder e também a reimplementação do form_for. No arquivo vendor/plugins/my_builder/init.rb, coloque o seguinte conteúdo:

require 'my_builder'

# define como o FormBuilder padrao
ActionView::Base.default_form_builder = MyFormBuilder

A última linha serve justamente para não termos que especificar o builder em cada form que fizermos, definindo nosso builder como o padrão.

Conclusões

FormBuilders são relativamente simples para personalizar e permitem remover muito código repetido de forma elegante, além de facilitar a manutenção. Pena que muita gente nem sabe que eles existem… espero que esse artigo tenha mostrado as possibilidades de uso dos builders e incentive o pessoal a usá-los mais. Quem quiser exemplos mais concretos, basta pesquisar no github, tem alguns plugins por lá .

Bons estudos!