ASCIIcasts - Full Episode Feed

Gravatar

Fri, 17 Dec 2010 00:08:07 +0000

Atualmente avatars são muito importantes, especialmente em aplicações sociais. Se você quer adicionar imagens de avatar para alguma aplicação, você deve dar uma olhada no Gravatar, que fornece uma maneira interessante de fazer isso. Tudo que você precisa é de um endereço de email para cada usuário, e assim não há necessidade da sua aplicação tratar arquivos anexos, crop de imagens, ou se preocupar se os usuários estão fazendo upload de imagens inapropriadas, pois isso é feito pelo Gravatar. Apenas forneça um endereço de email para o avatar do usuário será fornecido.

Vamos adicionar o Gravatar em uma simples aplicação Rails com um modelo User. Ela tem atualmente três usuários, cada um com um diferente endereço de email e a página index mostra uma coluna avatar com "TODO".

Existem muitos plugins disponíveis para adicionar o Gravatar ao Rails, mas é tão fácil fazer isso do zero que nós não queremos usar um plugin. Vamos começar modificando a view que renderiza a tabela mostrada acima. A view está assim:

/app/views/users/index.html.erb

<% for user in @users %>
  <tr>
    <td>TODO</td>
    <td><%= user.email %></td>
    <td><%= link_to "Show", user %></td>
    <td><%= link_to "Edit", edit_user_path(user) %></td>
    <td><%= link_to "Destroy", user, :confirm => 'Are you ↵
      sure?', :method => :delete %></td>
  </tr>
<% end %>

Vamos substituir o texto TODO, na primeira célula da tabela, com uma image_tag. A url da imagem será gerada por um método helper, que vamos escrever, chamado avatar_url. Ele recebe um usuário como parâmetro.

/app/views/users/index.html.erb

<% for user in @users %>
  <tr>
    <td><%= image_tag avatar_url(user) %></td>
    <td><%= user.email %></td>
    <td><%= link_to "Show", user %></td>
    <td><%= link_to "Edit", edit_user_path(user) %></td>
    <td><%= link_to "Destroy", user, :confirm => 'Are you ↵
      sure?', :method => :delete %></td>
  </tr>
<% end %>

Agora vamos escrever o método avatar_url no ApplicationHelper. O único truque é a geração do id que o Gravatar espera. O id é um hash MD5 em minúsculas do endereço de email do usuário, o que é bastante simples.

/app/helpers/application_helper.rb

module ApplicationHelper
  def avatar_url(user)
    gravatar_id = Digest::MD5::hexdigest(user.email).downcase
    "http://gravatar.com/avatar/#{gravatar_id}.png"
  end
end

Quando recarregarmos a página agora, vamos ver as imagens dos avatars para as duas contas que tem imagens do Gravatar associadas a elas. Para a que não tem, vamos ver uma imagem padrão do Gravatar.

Customizando imagens do Gravatar

Existem alguns parâmetros que podem ser passados na url do Gravatar para customizar seu comportamento e mais detalhes podem ser encontrados no site do Gravatar. Passando, por exemplo, o parâmetro s, vamos mudar o tamanho do avatar, assim:

http://gravatar.com/avatar/9a295994737a47683a4da4ed47aef7dd.png?s=200

A opção d pode ser usada para fornecer uma imagem alternativa, se não for encontrado um avatar para o usuário.

http://gravatar.com/avatar/84ce1adb94b67014236a909fa4c1269d.png?d=http%3A%2F%2Fasciicasts.com%2Fimages%2Frails.png

Podemos passar a opção r para mudar a classificação e se o seu site usa HTTPS, então podemos obter imagens com segurança usando o endereço https://secure.gravatar.com/. Vamos usar algumas dessas opções para redimensionar os avatars para 48 pixels, assim como o Twitter usa, e para fornecer uma imagem alternativa diferente.

/application/helpers/application_helper.rb

module ApplicationHelper
  def avatar_url(user)
    default_url = "#{root_url}images/guest.png"
    gravatar_id = Digest::MD5::hexdigest(user.email).downcase
    "http://gravatar.com/avatar/#{gravatar_id}.png?s=48&d=#{CGI.escape(default_url)}"
  end
end

Quando recarregarmos a página agora, as imagens estarão menores e nossa imagem padrão customizada será mostrada para a conta que não tem uma imagem no Gravatar.

Usando imagens de outros sites com OmniAuth

Essa solução de avatar funciona especialmente quando está junto com o OmniAuth. Se você não está familiarizado com o OmniAuth, o episódio 241 [assistir, ler] aborda como usá-lo em uma aplicação Rails. O motivo do OmniAuth funcionar bem aqui é que se um usuário entrar no seu site através do Facebook ou Twitter, então ele já terá um avatar desses serviços e ela pode ser obtida da propriedade image do hash user_info que o OmniAuth retorna. Se um usuário não entrou através de um desses serviços, então podemos usar o Gravatar como uma alternativa, para que cada usuário sempre tenha um avatar.

Não vamos adicionar o OmniAuth nessa aplicação, mas vamos adicionar um campo avatar_url ao nosso modelo User para simular essa parte dos dados do OmniAuth. Primeiro vamos modificar um dos usuários para adicionar o avatar do Twitter.

Depois vamos modificar nosso avatar_url no ApplicationHelper para que ele use o avatar já armazenado, se ele existir.

/app/helpers/application_helper.rb

module ApplicationHelper
  def avatar_url(user)
    if user.avatar_url.present?
      user.avatar_url
    else
      default_url = "#{root_url}images/guest.png"
      gravatar_id = Digest::MD5::hexdigest(user.email).downcase
      "http://gravatar.com/avatar/#{gravatar_id}.png?s=48&d=#{CGI.escape(default_url)}"
    end
  end
end

Quando recarregamos a página, o usuário que tiver um avatar armazenado, será mostrado. Para os outros, ainda pegaremos do Gravatar.

É isso. Foi rápido mas espero que tenha abordado tudo para você usar avatar nas suas aplicações Rails.

Beanstalkd e Stalker

Wed, 29 Dec 2010 23:17:27 +0000

No Rails Rumble desse ano, Ryan Bates e sua equipe criaram o site Go vs Go, onde você pode jogar Go (um jogo de tabuleiro) online. No site, você pode jogar contra outro jogador ou contra o computador. Quando você joga contra o computador, há um pequeno atraso após você mover sua pedra até o computador mover a dele. Isso acontece enquanto o computador calcula o seu movimento e, por padrão, prende um processo do Rails. Para evitar esse problema, a IA do jogo foi movida para um processo em segundo plano. Existem algumas maneiras de agendar processos em aplicações Rails, e a equipe do Go vs Go escolheu usar o beanstalkd. Nesse episódio vamos dar uma olhada no beanstalkd e na gem Stalker.

Começando com Beanstalkd

Se você está no OSX, há uma maneira fácil de instalar o beanstalkd, que é através do Homebrew. Nesse caso, você só precisa executar:

$ brew install beanstalkd

Depois de instalado, podemos iniciar o servidor do Beanstalkd executando o comando beanstalkd. Para executar como um processo daemon, podemos adicionar a opção -d.

$ beanstalkd -d

Para usar o Beanstalkd com Ruby vamos precisar instalar a gem beanstalk-clienk.

$ gem install beanstalk-client

Há instruções de como usar o Beanstalk com Ruby no site do Beanstalkd. Precisamos criar um novo Beanstalk::Pool e usar seu método put para adicionar uma tarefa na fila. E para trazer um item da fila, usamos o método reserve. Ele irá aguardar até uma tarefa estar disponível na fila e então irá retorná-la. Podemos assim processar a tarefa e então usar delete para removê-la da fila.

Vamos demonstrar isso em duas sessões irb. Em cada uma vamos criar um novo pool do Beanstalk em localhost:11300.

Top Window

$ irb
ruby-1.9.2-p0 > require 'beanstalk-client'
 => true 
ruby-1.9.2-p0 > beanstalk = Beanstalk::Pool.new(['localhost:11300'])
 => #<Beanstalk::Pool:0x00000100a9f8e8 @addrs=["localhost:11300"], @watch_list=["default"], @default_tube=nil, @connections={"localhost:11300"=>#<Beanstalk::Connection:0x00000100a9f7f8 @mutex=#<Mutex:0x00000100a9f780>, @waiting=false, @addr="localhost:11300", @socket=#<TCPSocket:fd 3>, @last_used="default", @watch_list=["default"]>}> 
ruby-1.9.2-p0 >

Bottom Window

$ irb
ruby-1.9.2-p0 > require 'beanstalk-client'
 => true 
ruby-1.9.2-p0 > beanstalk = Beanstalk::Pool.new(['localhost:11300'])
 => #<Beanstalk::Pool:0x00000101919bf8 @addrs=["localhost:11300"], @watch_list=["default"], @default_tube=nil, @connections={"localhost:11300"=>#<Beanstalk::Connection:0x00000101919978 @mutex=#<Mutex:0x000001019198d8>, @waiting=false, @addr="localhost:11300", @socket=#<TCPSocket:fd 3>, @last_used="default", @watch_list=["default"]>}> 
ruby-1.9.2-p0 >

Vamos adicionar uma tarefa na fila na janela superior, usando o put.

Top Window

ruby-1.9.2-p0 > beanstalk.put "hello"
 => 1

Na outra janela, vamos trazer aquela tarefa com reserve.

Bottom Window

ruby-1.9.2-p0 > job = beanstalk.reserve
 => (job server=localhost:11300 id=1 size=5)

Podemos então ver o body da tarefa e apagá-la da fila.

Bottom Window

ruby-1.9.2-p0 > job.body
 => "hello" 
ruby-1.9.2-p0 > job.delete
 => false

Se tentarmos dar reserve em outra tarefa agora, o comando vai aguardar, pois não há tarefas na fila.

Bottom Window

ruby-1.9.2-p0 > job = beanstalk.reserve

Agora que adicionamos outra tarefa, ela será retornada imediatamente.

Top Window

ruby-1.9.2-p0 > beanstalk.put "bacon"
 => 2

Bottom Window

ruby-1.9.2-p0 > job = beanstalk.reserve
 => (job server=localhost:11300 id=2 size=5)

A nova tarefa é processada imediatamente. Isso ajuda na resposta do Go vs Go, pois significa que o computador vai responder assim que possível.

Usando o Beanstalk em uma aplicação Rails

Vamos ver como usar o Beanstalkd em uma aplicação Rails. Temos uma aplicação simples que nos permite criar cidades. Tudo que precisamos fazer é fornecer um código postal e uma cidade será criada. O nome da cidade virá de um site externo.

Embora trazer o nome da cidade seja geralmente uma chamada rápida, uma requisição separada pode ser lenta, por isso vamos movê-la para um processo em segundo plano.

Antes estavamos usando a gem Beanstalk client diretamente, mas em uma aplicação Rails vamos usar outra gem chamada Stalker. Ela usa a gem cliente e fornece uma interface melhor para trabalhar. Para usar o Stalker em nossa aplicação Rails, só precisamos adicioná-la ao Gemfile.

/Gemfile

source 'http://rubygems.org'

gem 'rails', '3.0.3'
gem 'nifty-generators'
gem 'sqlite3-ruby', :require => 'sqlite3'
gem 'stalker'

E vamos instalar executando o bundle.

Podemos agora mover o código que traz os nomes das cidades para um processo separado em segundo plano. A action create atualmente salva a nova cidade e então chama um método do modelo City chamado fetch_name para determinar o nome da cidade. Esse método chama uma API externa que traz o nome da cidade. É isso que queremos mover para um processo em segundo plano.

/app/controllers/cities_controller.rb

def create
  @city = City.new(params[:city])
  if @city.save
    @city.fetch_name
    redirect_to city_path(@city), :notice => "Successfully ↵
      created city."
  else
    render :action => 'new'
  end
end

Vamos modificar o código para que, em vez de chamar @city.fetch_name, ele adicione uma tarefa na nossa fila. Podemos fazer isso chamando Stalker.enqueue. Precisamos dar um identificador para a nova tarefa, então vamos chamá-la de city.fetch_name. Podemos também passar opções para a tarefa; vamos passar o id da cidade que acabamos de salvar.

/app/controllers/cities_controller.rb

def create
  @city = City.new(params[:city])
  if @city.save
    Stalker.enqueue("city.fetch_name", :id => @city.id)
    redirect_to city_path(@city), :notice => "Successfully ↵
      created city."
  else
    render :action => 'new'
  end
end

Agora precisamos criar uma nova tarefa Stalker para lidar com isso. Podemos em qualquer lugar na nossa aplicação Rails; vamos criar no diretório config, um arquivo chamado jobs.rb.

Stalker tem uma API simples para gerenciamento de tarefas. Tudo que precisamos fazer é chamar o método job e passar um identificador. Esse método também recebe um bloco, que tem como argumentos, os argumentos passados para o Stalker.enqueue anteriormente. Nesse bloco, pegamos a cidade com o id correto e chamamos o método fetch_name. O Stalker não carrega o ambiente do Rails por padrão, por isso é necessário dar require no arquivo config/environment.rb na primeira linha do código abaixo:

/config/jobs.rb

require File.expand_path("../environment", __FILE__)

job "city.fetch_name" do |args|
  City.find(args["id"]).fetch_name
end

Podemos executar nossas tarefas executando o comando stalk passando o nome do arquivo que queremos executar.

$ stalk ./config/jobs.rb

Temos o Beanstalkd executando. Se criarmos uma nova cidade, seu nome ficará em branco.

Quando recarregamos a página algumas vezes, o nome aparece.

Isso mostra que a tarefa está sendo processada com sucesso em segundo plano. Se olharmos o log, vamos ver a tarefa listada.

[2010-12-09 19:04:49 +0000] -> city.fetch_name (id=2)
[2010-12-09 19:04:50 +0000] -> city.fetch_name finished in 374ms

Otimizando o processo em segundo plano

Um problema da nossa tarefa é que ela está carregando todo o ambiente Rails. Se tivermos vários processos para lidar com as tarefas, isso vai nos levar a um gasto muito grande de memória. Ter o ambiente Rails disponível não é necessário e podemos fazer o processo mais eficiente sem ele. Para fazer isso, vamos alterar a tarefa para ela acessar o banco de dados sem o ActiveRecord.

/config/jobs.rb

require 'sqlite3'
require 'json'
require 'net/http'

RAILS_ENV = ENV["RAILS_ENV"] || "development"

db = SQLite3::Database.new(File.expand_path( ↵
  "../../db/#{RAILS_ENV}.sqlite3", __FILE__))

job "city.fetch_name" do |args|
  postcode = db.get_first_value("SELECT postcode FROM ↵
    cities WHERE id=?", args["id"])
  url = "http://ws.geonames.org/postalCodeLookupJSON?  ↵
    postalcode=#{CGI.escape(postcode)}&country=GB"
  json = Net::HTTP.get_response(URI.parse(url)).body
  name = JSON.parse(json)["postalcodes"].first["placeName"]
  db.execute("UPDATE cities SET name=? WHERE id=?", ↵
    args["id"], name)
end

No código acima, pegamos o código postal no banco de dados e trazemos o nome da cidade através da API. Depois fazemos o parser da resposta JSON para pegar o nome da cidade. E assim atualizamos o registro no banco de dados. Tudo isso é feito sem usar o modelo City ou qualquer coisa da aplicação Rails. Isso vai manter o processo muito mais enxuto.

Tratamento de Erros

O que acontece se uma exceção é lançada quando tentamos pegar o nome da cidade? Nesses casos o Stalker vai gerar o log do erro e vai tentar executar um manipulador de erros. Podemos criar um manipulador escrevendo um método error.

/config/jobs.rb

error do |exception|
  # Code to handle the error.
end

Quando isso acontece o Stalker vai abandonar a tarefa no Beanstalk, isso significa que o Beanstalk não vai tentar colocá-la na fila novamente, a menos que a gente use o comando kick. Para isso, conectamos por telnet diretamente no Benstalkd.

$ telnet localhost 11300
Trying ::1...
Connected to localhost.
Escape character is '^]'.

Depois de conectado, vamos executar o comando kick, passando o número de tarefas que queremos colocar de volta na fila.

kick 10
KICKED 0

Não temos qualquer tarefa abandonada, então recebemos KICKED 0 como resposta.

Agora podemos tratar exceções de uma tarefa, mas e se o processo de segundo plano morrer completamente? Devemos monitorar o processo para assegurarmos que ele está funcionando. Podemos fazer isso usando a ferramenta God. Falamos dessa ferramenta em detalhes no episódio 130. Abaixo está um arquivo de configuração para executar tarefas Stalker em segundo plano. Uma vantagem deste método é que ele automaticamente faz o daemon do processo para que nós não tenhamos que nos preocupar com isso.

Se você olhar o arquivo de configuração abaixo, vai ver que ele chama o stalk com nosso arquivo jobs.rb passado como parâmetro. O resto do arquivo é um conjunto bastante comum de configurações que assegura que ele permaneça em funcionamento e não comece a usar muita memória ou CPU.

/config/god.rb

# run with: god -c config/god.rb
RAILS_ROOT = File.expand_path("../..", __FILE__)

God.watch do |w|
  w.name = "anycity-worker"
  w.interval = 30.seconds
  w.env = {"RAILS_ENV" => "production"}
  w.start = "/usr/bin/stalk #{RAILS_ROOT}/config/jobs.rb"
  w.log = "#{RAILS_ROOT}/log/stalker.log"

  w.start_if do |start|
    start.condition(:process_running) do |c|
      c.running = false
    end
  end

  w.restart_if do |restart|
    restart.condition(:memory_usage) do |c|
      c.above = 50.megabytes
      c.times = [3, 5] # 3 out of 5 intervals
    end

    restart.condition(:cpu_usage) do |c|
      c.above = 50.percent
      c.times = 5
    end
  end

  w.lifecycle do |on|
    on.condition(:flapping) do |c|
      c.to_state = [:start, :restart]
      c.times = 5
      c.within = 5.minute
      c.transition = :unmonitored
      c.retry_in = 10.minutes
      c.retry_times = 5
      c.retry_within = 2.hours
    end
  end
end

Persistindo Beanstalk

Só mais uma coisa para se manter em mente é que o Beanstalk por padrão não é persistente. Se você executá-lo como fizemos com opção -d e o processo morrer em seguida, todas as tarefas que estavam na fila aguardando para serem processadas são perdidas, pois elas são armazenadas na memória. Para tornar persistente, podemos executá-lo com a opção -b e passar-lhe o caminho para um diretório binlog.

beanstalkd -d -b /Users/eifion/binlog

Dessa forma a fila será restaurada caso o processo falhe.

Mongoid

Wed, 29 Dec 2010 23:07:27 +0000

Há alguns meses atrás no Episódio 194 [ver, ler] covered MongoDB e MongoMapper. MongoMapper é uma gema grande, mas agora existe uma alternativa chamada Mongoid que vale a pena considerar se você está pensando em usar MongoDB como o back-end de uma aplicação Rails. Uma das coisas que faz stand Mongoid fora é o seu site, que parece ótimo e que tem documentação detalhada. Mongoid é um projeto de outros projetos open-source que você pode aprender.

Instalando o MongoDB

Se você ainda não tem instalado em seu sistema o MongoDB a primeira coisa que você precisa fazer é acessar o página de downloads do MongoDB e baixar os arquivos apropriados. Se você estiver usando Mac OS X, então você pode instalar MongoDB atravez do Homebrew. Uma vez instalado, você pode verificar se está funcionando MongoDB visitando http://localhost:28017. Se você ver uma página como a abaixo, em seguida, significa que tudo está funcionando corretamente.

Criando uma nova aplicação Rails utilizando o Mongoid

Agora que já temos o MongoDB instalado, vamos criar uma nova aplicação Rails 3 que usa Mongoid. Como é tradição de uma aplicações Rails de exemplo, esta será uma aplicação de blog.

$ rails new blog

A primeira coisa que precisamos fazer é adicionar a gema Mongoid ao Gemfile. No momento da versão escrita é a 2, que é a versão que o Rails 3 suporta, ainda está em beta, então vamos precisar especificar o número da versão.

/Gemfile

source 'http://rubygems.org'

gem 'rails', '3.0.1'
gem 'sqlite3-ruby', :require => 'sqlite3'

gem 'mongoid', '2.0.0.beta.19'
gem 'bson_ext'

Precisamos também de adicionar o bson_ext gem. BSON é uma versão binária do JSON e esta gema fornece algumas extensões C para acelerar a serialização Ruby BSON. Podemos, então, instalar as gema da maneira usual.

$ bundle install

Uma vez que as gemas tenham sido instaladas, precisaremos executar o gerador de configuração do Mongoid para que ele possa criar o arquivo de configuração YAML.

$ rails g mongoid:config

O arquivo padrão é mostrado abaixo. Podemos deixá-lo como ele é enquanto estamos desenvolvendo a nossa aplicação.

/config/mongoid.yml

defaults: &defaults
  host: localhost
  # slaves:
  #   - host: slave1.local
  #     port: 27018
  #   - host: slave2.local
  #     port: 27019

development:
  <<: *defaults
  database: blog_development

test:
  <<: *defaults
  database: blog_test

# set these environment variables on your prod server
production:
  host: <%= ENV['MONGOID_HOST'] %>
  port: <%= ENV['MONGOID_PORT'] %>
  username: <%= ENV['MONGOID_USERNAME'] %>
  password: <%= ENV['MONGOID_PASSWORD'] %>
  database: <%= ENV['MONGOID_DATABASE'] %>

Tudo está no lugar agora para nós poder começar a desenvolver a nossa aplicação. Vamos começar criando um modelo Artigo com os campos nome e conteúdo, e iremos usar o scaffolding do Rails para criar o controlador associado e visualização de código.

$ rails g scaffold article name:string content:text
    invoke  mongoid
    create    app/models/article.rb

Mongoid fornece geradores para os modelos modo que o gerador Mongoid o modelo é chamado quando um modelo é criado e, portanto, o ActiveRecord não é usado. Se abrirmos o arquivo do modelo, iremos ver que é uma classe simples foi incluida Mongoid::Document.

/app/models/article.rb

class Article
  include Mongoid::Document
  field :name, :type => String
  field :content, :type => String
end

Uma diferença é que esta classe vem a partir de uma classe model do ActiveRecord é que cada campo é explicitamente definido, junto com seu tipo. O tipo padrão é String, para que possamos remover os tipos desta classe, se quisermos.

/app/models/article.rb

class Article
  include Mongoid::Document
  field :name
  field :content
end

Agora a nossa aplicação está pronto para ser executada. Nós não precisamos executar qualquer banco de dados como migração do MongoDB, com o schema-lesse podemos passar todos os campos que preferimos em um documento. Se você visitar a página /articles, iremos ver a página usual gerada pelo scaffold, e podemos criar um novo Artigo, assim como nós, se tivéssemos um ActiveRecord como back-end.

Adicionando campos

Uma das grandes vantagens de se usar o schema-less como banco de dados, é que é bastante simples de adicionar novos campos ao modelo. Vamos dizer que se esqueceu de acrescentar uma data de publicação do Artigo. Para adicionar um só precisamos modificar a classe do modelo.

/app/models/article.rb

class Article
  include Mongoid::Document
  field :name
  field :content
  field :published_on, :type => Date
end

Para que possamos visualizar e modificar o campo da data de publicação, iremos modificar o código da view e adicionar o novo campo ao formulário.

/app/views/articles/_form.html.erb

 <div class="field">
    <%= f.label :name %><br />
    <%= f.text_field :name %>
  </div>
  <div class="field">
    <%= f.label :published_on %><br />
    <%= f.date_select :published_on %>
  </div>
  <div class="field">
    <%= f.label :content %><br />
    <%= f.text_area :content %>
  </div>
  <div class="actions">
    <%= f.submit %>
  </div>

E também a view para a ação do show.

/app/views/articles/show.html.erb

<p id="notice"><%= notice %></p>

<p>
  <b>Name:</b>
  <%= @article.name %>
</p>

<p>
  <b>Content:</b>
  <%= @article.content %>
</p>

<p>
  <b>Published:</b>
  <%= @article.published_on %>
</p>


<%= link_to 'Edit', edit_article_path(@article) %> |
<%= link_to 'Back', articles_path %>

Agora podemos editar o artigo que acabamos de criar e adicionar uma data de publicação.

Validações

O Mongoid utiliza o ActiveModel, o que significa que muitas das funcionalidades que usamos no ActiveRecord está disponível para nós aqui também, por exemplo validações, callbacks, dirty tracking, attr_accessible, e assim por diante. Com isto, se torna mais fácil adicionar as validações de modelos como os ActiveRecord do Mongoid.

/app/models/article.rb

class Article
  include Mongoid::Document
  field :name
  field :content
  field :published_on, :type => Date
  validates_presence_of :name
end

Se tentarmos criar um artigo sem um nome agora, iremos começar a ver os erros de validação o mesmo que veríamos por um modelo equivalente ao ActiveRecord.

Associações

Não podemos ter um blog sem comentários, então iremos criar um modelo para Comentário ao longo associação, modo que cada artigo pode ter muitos comentários. Há duas maneiras para definir as associações com Mongoid. A primeira é através de uma associação de referência. Esta se comporta de maneira similar às relações entre tabelas no ActiveRecord e bancos de dados relacionais em que existem dois registros separados que estão relacionados através de uma coluna id. A outra maneira é uma associação incorporado, o que significaria, neste caso, os comentários estão incorporados dentro do mesmo documento que o artigo.

Em quanto você está decidindo qual destas abordagens, é a utilização que você precisa se perguntar se você realmente necessita dos registros associados por ficar por conta própria ou se você vai sempre acessá-los através do seu modelo pai. Neste caso, só vamos sempre estar recebendo comentários através de seu artigo associado por isso vamos usar uma associação incorporado. Nós definimos o relacionamento na classe de Artigo usando o método embeds_many.

/app/models/article.rb

class Article
  include Mongoid::Document
  field :name
  field :content
  field :published_on, :type => Date
  validates_presence_of :name
  embeds_many :comments
end

Em seguida, vamos gerar o modelo de Comentário.

$ rails g model comment name:string content:text

Nesta nova classe Comentário, podemos agora definir a sua relação com o Artigo.

/app/models/comment.rb

class Comment
  include Mongoid::Document
  field :name
  field :content
  embedded_in :article, :inverse_of => :comments
end

Usamos embedded_in para definir a relação de um comentário a um artigo. A opção inverse_of é necessário dizer ao Mongoid que o comentário deve ser incorporado completamente.

A fim de criar comentários para cada artigo e vê-los vamos precisar criar um CommentsController e algumas views, mas antes de fazermos isso iremos precisar alterar o arquivo de rotas. Para as associações incorporadas como esta, geralmente queremos usar rotas aninhadas como o objeto filho é sempre acessado através de seu pai e por isso iremos utilizar o nested do recurso comentários em artigos.

/config/routes.rb

Blog::Application.routes.draw do
  resources :articles do
    resources :comments
  end
end

Em seguida, iremos gerar o controller.

$ rails g controller comments

No controller iremos escrever uma criar uma ação para que possamos criar novas observações para um artigo. Com esta ação irá encontrar um artigo com base no parâmetro article_id, crie um comentário para este artigo e, em seguida redirecionar de volta para a página do artigo.

/app/controllers/comments_controller.rb

CommentsController < ApplicationController
  def create
    @article = Article.find(params[:article_id])
    @comment = @article.comments.create!(params[:comment])
    redirect_to @article, :notice => "Comment created!"  
  end
end

Finalmente, iremos adicionar algum código na view dos artigos, que irá mostrar os comentários de um artigo e permitir que os comentários sejam adicionados.

/app/views/articles/show.html.erb

<% if @article.comments.size > 0 %>
  <h2>Comments</h2>
  <% for comment in @article.comments %>
    <h3><%= comment.name %></h3>
    <p><%= comment.content %></p>
  <% end %>
<% end %>

<h2>New Comment</h2>

<%= form_for [@article, Comment.new] do |f| %>
  <p><%= f.label :name %> <%= f.text_field :name %></p>
  <p><%= f.text_area :content, :rows => 10 %></p>
  <p><%= f.submit %></p>
<% end %>

Ao visitar a página de um artigo agora nós iremos ser capazes de criar um novo comentário e depois de ter submetido será mostrado abaixo do artigo.

Se dermos uma olhada no log do desenvolvimento, podemos ver as consultas do MongoDB. Quando criamos um comentário agora, essa consulta foi feita.

MONGODB blog_development['articles'].update({"_id"=>BSON::ObjectId('4cd01fa4a74209eacc000003')}, 
{"$push"=>{"comments"=>{"_id"=>BSON::ObjectId('4cd04c74a74209ecb4000002'), 
  "name"=>"Eifion", "content"=>"I agree."}}})

As atualizações que consultam um modelo de artigo e acrescenta um novo comentário atribuir-lhe que os comentários não são armazenados separadamente. Isto significa que, se abrirmos o console do Rails e contar todos os comentários, teremos um resultado inesperado.

> Comment.count
 => 0

Os comentários que temos são incorporados em objetos e não estão disponíveis a nível global do documento. Para acessá-los, sempre temos que atravessar seu artigo associado.

>   Article.first.comments.count
 => 1

Para chegar aos atributos de um comentário, nós sempre necessitamos começar esse comentário através de uma associação, como esta aplicação, os comentários são incorporados aos registros.

Tipo de associações de referências

Se queremos um registro associado que também esteja disponível como um documento separado, então iremos necessitar de um para criar uma associação de tipo de referência. Nós iremos demonstrar isso modificando o nosso pedido para que possamos associar cada artigo de um autor. Primeiro iremos gerar um scaffold para um modelo novo Autor.

$ rails g scaffold author name:string

Antes de demonstrar associações vamos dar uma rápida olhada em um recurso interessante do Mongoid. Se nós adicionamos um método essencial para Mongoid classe de modelo que a key> será usada como o id para identificar esse modelo. Nós iremos fazer o nome do atributo a chave para o Autor.

/app/models/author.rb

class Author
  include Mongoid::Document
  field :name
  key :name
end

Se criarmos um autor, agora, quando estamos redirecionado para a página do autor, vamos ver o id na URL.

Se vamos utilizar esse recurso, então iremos precisar de assegurar o campo que escolhemos para usar como uma chave não editável para que o documento tenha uma seqüência permanente como um id que não vai mudar toda a vida do documento.

Voltar para associações de agora. Na classe Autor usamos references_many para definir o relacionamento com os artigos.

/app/models/author.rb

class Author
  include Mongoid::Document
  field :name
  key :name
  references_many :articles
end

Então, no modelo de Artigo que usamos o referenced_in.

/app/models/article.rb

class Article
  include Mongoid::Document
  field :name
  field :content
  field :published_on, :type => Date
  validates_presence_of :name
  embeds_many :comments
  referenced_in :author
end

Podemos agora usar essa associação como faríamos no ActiveRecord. Em nosso formulário para editar um artigo, podemos adicionar uma collection_select para que possamos selecionar um autor quando criar ou atualizar um artigo.

/app/views/articles/_form.html.erb

<div class="field">
  <%= f.label :author_id %><br />
  <%= f.collection_select :author_id, Author.all, :id, :name %>
</div>

Se modificarmos nosso artigo agora e selecionar um autor que vai pode ver que o autor do id incorporado no artigo quando examiná-lo no console.

> Article.first
 => #<Article _id: 4cd01fa4a74209eacc000003, name: "Mongoid", content: "it's awesome!", published_on: 2010-11-02 00:00:00 UTC, author_id: "eifion-bedford">

Diferentemente da associação comentários, no entanto, podemos acessar o autor separadamente.

> Author.first
 => #<Author _id: eifion-bedford, name: "Eifion Bedford">

Isso é tudo para este episódio sobre Mongoid. Há muito que não temos tratado aqui, mas a documentação é bastante abrangente e irá dar-lhe quase tudo o que você precisa saber para usar o Mongoid e o MongoDB na sua aplicação Rails.

Usando attr_accessible dinamicamente.

Tue, 09 Nov 2010 09:40:31 +0000

Há mais de três anos, no episódio 26 [assistir, ler] falamos sobre atribuição em massa e como isso pode causar problemas de segurança. O Rails 3 foi lançado e possui várias características mais seguras que já vêm habilitadas por padrão, mas não é o caso das atribuições em massa. Os modelos das aplicações Rails precisam ter seus atributos protegidos, para evitar que usuários mal intencionados atualizem esses atributos enviando-os para o servidor através de requisições POST. Se você não conhece esse problema, dê uma olhada no episódio 26, mas o importante é saber que sempre que você criar ou atualizar uma instância de um modelo nos seus controllers, usando atribuição em massa, é necessário usar o método attr_accessible nos modelos, para proteger os atributos que você não quer que sejam atualizados. Caso você não faça isso, os usuários poderão atualizar quaisquer atributos e isso pode levar a um enorme problema de segurança.

É simples chamar o métodoattr_accessible em cada modelo, porém existem dois problemas em potencial quando isso é feito. O primeiro problema ocorre quando você está testando sua aplicação. Algumas vezes você quer fazer atribuição em massa durante os testes e com os modelos protegidos pelo attr_accessible isso pode se tornar muito difícil. Uma solução para esse problema é usar factories, como foi mostrado no episódio 158 [assistir, ler].

O segundo problema é que o attr_accessible não é dinâmico. Os atributos que são especificados nele para um dado modelo são fixos. E alterar esses atributos baseado nas permissões dos usuários, por exemplo, pode ser difícil. Isso acontecia no Rails 2, mas o Rails 3 fornece uma nova maneira de termos atributos dinâmicos e vamos mostrar isso neste episódio.

Nosso Wiki Site

Para demonstrar os atributos dinâmicos, vamos usar um wiki site. Esse site tem alguns artigos e um artigo pode ser editado por qualquer pessoa. No formulário de edição, juntamente com os campos nome e conteúdo, está um checkbox que permite que um usuário marque um artigo como 'importante'.

Quando um artigo é marcado como importante, seu título aparece em vermelho.

Vamos modificar a aplicação de forma que somente os administradores possam alterar a importância de um artigo. Usuários não administradores não devem poder alterar o campo important. É fácil modificar o formulário e mostrar o checkbox somente para os administradores, porém isso não resolve o problema, pois ainda será possível que os usuários ignorem esse formulário e façam uma requisição POST que modifique o campo important de um artigo.

A solução para esse problema está nas camadas de modelos e controllers, especificamente nas actions create e update do ArticlesController, pois é onde a atribuição em massa acontece. Uma abordagem que poderíamos ter para proteger o atributo important, seria removê-lo dos params a menos que o usuário atual seja um administrador.

/app/controllers/articles_controller.rb

def update
  params[:article].delete(:important) unless admin?
  @article = Article.find(params[:id])
  if @article.update_attributes(params[:article])
    flash[:notice] = "Successfully updated article."
    redirect_to @article
  else
    render :action => 'edit'
  end
end

O problema dessa solução é que temos que lembrar de fazer isso para todos os atributos que queremos proteger. E também não vai existir uma correlação com a chamada ao attr_accessible no model. Seria muito melhor se pudéssemos ter um attr_accessible dinâmico.

Vamos dar uma olhada na documentação da API do Rails para ver se encontramos algo sobre o attr_accessible que possa ajudar. Uma coisa interessante mostrada na documentação é que o attr_accessible agora está no módulo ActiveModel::MassAssignmentSecurity, e não mais diretamente no ActiveRecord. Isso significa que ele pode ser incluído e usado em qualquer classe, o que é muito mais flexível. No topo da documentação, tem um exemplo de uso do ActiveModel::MassAssignmentSecurity diretamente no controller, em vez de estar no modelo, o que é realmente uma boa ideia. Uma coisa realmente interessante é o código que mostra como tornar o attr_accessible dinâmico sobrescrevendo o método mass_assignment_authorizer.

def mass_assignment_authorizer
  admin ? admin_accessible_attributes : super
end

O código acima muda o comportamento da aplicação baseado no fato do usuário ser um admin ou não. Isso é exatamente o que queremos fazer. Sobrescrevendo esse método nos nossos modelos, podemos alterar os campos que podem ser modificados pela atribuição em massa usando qualquer condição.

Nosso modelo Article atualmente está assim:

/app/models/article.rb

class Article < ActiveRecord::Base
  attr_accessible :name, :content, :important
end

Essa é uma classe simples somente com uma chamada ao attr_accessible passando três atributos. O atributo :important é o único que queremos tornar dinâmico e podemos fazer isso sobrescrevendo o método mass_assignment_authorizer.

/app/models/article.rb

class Article < ActiveRecord::Base
  attr_accessible :name, :content
  
  private
  def mass_assignment_authorizer
    super + [:important]
  end
end

Chamando super no método mass_assignment_authorizer estamos obtendo o comportamento padrão, o qual retorna uma "whitelist sanitizer". Você não precisa saber exatamente como isso funciona para poder usar. Só precisa saber que você pode adicionar mais atributos a ele como fizemos anteriormente. Uma vez que adicionamos esse parâmetro extra, podemos removê-lo da lista de parâmetros do attr_accessible.

As alterações que fizemos até agora não alteraram o comportamento da nossa aplicação toda, mas podemos tornar a acessibilidade do :important dinâmica agora, pois ele está definido em uma variável de instância em vez de estar no nível da classe. Vamos fazer isso adicionando uma variável à classe que vai conter uma lista de atributos que queremos tornar acessíveis.

/app/models/article.rb

class Article < ActiveRecord::Base
  attr_accessible :name, :content
  attr_accessor :accessible
  
  private
  def mass_assignment_authorizer
    super + (accessible || [])
  end
end

Qualquer parâmetro passado para o accessible vai ser adicionamdo à lista de atributos acessíveis e podemos usar isso em nossos controllers. Vamos modificar a action update para que seja adicionado o parâmetro :important somente se o usuário atual for um admin.

/app/controllers/articles_controller.rb

def update
  @article = Article.find(params[:id])
  @article.accessible = [:important] if admin?
  if @article.update_attributes(params[:article])
    flash[:notice] = "Successfully updated article."
    redirect_to @article
  else
    render :action => 'edit'
  end
end

Podemos iniciar nossa aplicação para ver se as alterações funcionaram. Se entramos na aplicação com uma conta que não é de admin, e editarmos um artigo, marcando esse artigo como importante, quando estivermos de volta à página de artigos, o título estará preto, indicando que o campo important não foi alterado.

Se transformarmos a nossa conta em administrador e editarmos o artigo novamente, o campo important estará atualizado e o título mudará de cor.

Os admins devem poder editar quaisquer campos, por isso seria útil se o accessible suportasse uma opção :all, que nos permitiria facilmente deixar todos os atributos do modelo editáveis. Podemos fazer isso modificando o mass_assignment_authorizer.

/app/models/article.rb

def mass_assignment_authorizer
  if accessible == :all
    self.class.protected_attributes
  else
    super + (accessible || [])
  end
end

O método agora verifica se o accessible é igual a :all. Se é igual, então precisamos retornar algo que tornará todos os atributos editáveis. Seria bom se pudéssemos retornar simplesmente um array vazio, mas infelizmente o objeto que é retornado pelo mass_assignment_authorizer é um objeto sanitizer, então isso não funciona. O jeito que temos trabalhado com isso é meio hack, mas funciona bem: retornamos self.class.protected_attributes. Isso é usado pelo módulo MassAssignmentSecurity para prover uma lista negra de atributos que não podem ser modificados. Como nós não usamos attr_protected nessa classe, isso vai permitir todos os atributos, que é justamente o que queremos aqui. Podemos agora modificar o ArticlesController para tornar todos os atributos do Article acessíveis, passando :all.

/app/controllers/articles_controller.rb

def update
  @article = Article.find(params[:id])
  @article.accessible = :all if admin?
  if @article.update_attributes(params[:article])
    flash[:notice] = "Successfully updated article."
    redirect_to @article
  else
    render :action => 'edit'
  end
end

Se testarmos isso na aplicação, vamos ver que os admins ainda podem editar o atributo important.

No controller, precisamos ainda aplicar a opção accessible para a action create. Se nós simplesmente aplicarmos como está não vai funcionar.

/app/controllers/articles_controller.rb

@article = Article.new(params[:article])
@article.accessible = :all if admin?

Não funciona porque a atribuição em massa acontece na chamada ao método new, então aplicamos o accessible tarde demais. Precisamos separar a criação de um novo Article da atribuição dos seus atributos e fazer a chamada ao accessible entre os dois.

/app/controllers/articles_controller.rb

def create
  @article = Article.new
  @article.accessible = :all if admin?
  @article.attributes = params[:article]
  if @article.save
    flash[:notice] = "Successfully created article."
    redirect_to @article
  else
    render :action => 'new'
  end
end

Você pode querer fazer isso de forma mais abstrata e remover a duplicação no código das duas actions, mas isso depende de como o seu sistema de permissões funciona, então vamos deixar por sua conta. Uma alteração que ainda vamos fazer é extrair o método mass_assignment_authorizer para fora do modelo Article, para que isso possa ser usado em todos os modelos da aplicação.

Vamos mover o método para um initializer. No diretório /config/initializers, vamos criar um novo arquivo chamado accessible_attributes.rb.

/config/initializers/accessible_attributes.rb

class ActiveRecord::Base
  attr_accessible
  attr_accessor :accessible
  
  private
  def mass_assignment_authorizer
    if accessible == :all
      self.class.protected_attributes
    else
      super + (accessible || [])
    end
  end
end

Esse initializer modifica o ActiveRecord::Base para o comportamento ser aplicado a todos os modelos. Note que ainda podemos chamar o attr_accessible sem argumentos. Isso significa que o comportamento padrão será de forma que nenhum atributo pode ser modificado através de atribuição em massa. E que vamos ter que adicionar uma chamada a attr_accessible em cada modelo que tenha atributos editáveis. Podemos agora organizar o model Article assim:

/app/models/article.rb

class Article < ActiveRecord::Base
  attr_accessible :name, :content
end

É isso. Nós fizemos o attr_accessible completamente dinâmico e podemos alterar seus atributos baseado nas permissões dos usuários. O bom disso é que tudo está bloqueado por padrão. E o acesso é dado somente onde especificarmos explicitamente no código. Isso torna a atribuição em massa um problema muito menor, pois por padrão todos os atributos estão seguros.

SimpleForm

Wed, 13 Oct 2010 21:54:08 +0000

Há alguns meses, dois episódios falaram sobre a gem Formtastic [assistir, ler]. Ela oferece uma maneira prática de gerar o código para exibir formulários em Rails. Nesse episódio vamos dar uma olhada em uma outra gem chamada SimpleForm. Assim como Formtastic, SimpleForm fornece uma maneira simples de gerar o código dos formulários nas views, se comparado com a maneira padrão do Rails. Se você conhece o Formtastic, então o SimpleForm vai parecer bem familiar, pois eles são realmente muito semelhantes.

A grande pergunta aqui é: dado que as gems são similares, porque você deveria escolher usar SimpleForm em vez de Formtastic? Um motivo é que o SimpleForm é mais leve. Ela é também mais customizável e extensível que o Formtastic. Se você usou o Formtastic e sente que ele se mete no seu caminho, então é bom dar uma olhada no SimpleForm.

Integrando SimpleForm em uma Aplicação

Para demonstrar o SimpleForm, vamos atualizar um formulário escrito usando o código padrão de views do Rails para usar o SimpleForm. A aplicação é um simples comércio eletrônico com um número de produtos, cada qual pertence a uma categora e o formulário que vamos modificar é o formulário de criação de um novo produto. Esse formulário tem diferentes tipos de campos e será um bom exemplo para usar o SimpleForm.

Para usar o SimpleForm, temos primeiro que adicionar a gem no Gemfile da aplicação.

/Gemfile

gem "simple_form"

E para termos certeza de que está instalada, precisamos executar:

$ bundle install

Agora que a gem está instalada, precisamos executar um generator que adicionará uns poucos arquivos que o SimpleForm precisa dentro da nossa aplicação.

$ rails g simple_form:install
    create  config/initializers/simple_form.rb
    create  config/locales/simple_form.en.yml
    create  lib/templates/erb/scaffold/_form.html.erb

Esses arquivos gerados são usados principalmente para customização e iremos dar uma olhada neles rapidamente. Antes, vamos atualizar o código do nosso formulário de cadastro de produtos que está assim:

/app/view/products/new.html.erb

<%= form_for @product do |f| %>
  <%= f.error_messages %>
  <p>
    <%= f.label :name %>
    <%= f.text_field :name %>
  </p>
  <p>
    <%= f.label :price %>
    <%= f.text_field :price %>
  </p>
  <p>
    <%= f.label :released_on %>
    <%= f.date_select :released_on %>
  </p>
  <p>
    <%= f.label :category_id %>
    <%= f.collection_select :category_id, Category.all, :id, :name %>
  </p>
  <p>
    <%= f.label :rating %>
    <%= f.select :rating, 1..5 %>
  </p>
  <p>
    <%= f.label :discontinued %>
    <%= f.check_box :discontinued %>
  </p>
  <p><%= f.submit %></p>
<% end %>

As duas principais mudanças que precisamos fazer são substituir o form_for pelo simple_form_for e substituir cada par de labels e inputs com um dos métodos do SimpleForm.

/app/view/products/new.html.erb

<%= simple_form_for @product do |f| %>
  <%= f.error_messages %>
  <%= f.input :name %>
  <%= f.input :price %>
  <%= f.input :released_on %>
  <%= f.association :category %>
  <%= f.input :rating %>
  <%= f.input :discontinued %>
  <%= f.button :submit %>
<% end %>

Para a maior parte dos controles no formulário, podemos usar o métodof.input. Um campo onde precisamos usar algo diferente é o category. No formulário original, esse campo usava collection_select para renderizar um menu drop down contendo todas as categorias.

/app/view/products/new.html.erb

<%= f.collection_select :category_id, Category.all, :id, :name %>

Com o SimpleForm, podemos substituir por f.association, que faz a mesma coisa.

Podemos recarregar o formulário e ver como ele está sendo renderizado pelo SimpleForm.

O formulário parece um pouco diferente agora pois não tem mais o estilo que tinha anteriormente. Mas é fácil alterar nosso css para adicionar alguns estilos e classes que o SimpleForm usa em seus formulários.

/public/stylesheets/application.css

.simple_form label {
  float: left;
  width: 100px;
  text-align: right;
  margin: 2px 10px;
}

.simple_form div.input {
  margin-bottom: 10px;
}

.simple_form div.boolean, .simple_form input[type='submit'] {
  margin-left: 120px;
}

.simple_form div.boolean label {
  float: none;
  margin: 0;
}

Quando você usar o SimpleForm em sua própria aplicação, vai querer customizar o estilo de acordo com o design da sua aplicação. O CSS acima vai te dar uma ideia de quais os nomes das classes usados nos elementos HTML que o SimpleForm gera. Com o estilo acima aplicado, nosso formulário parece um pouco melhor.

Personalizando Campos

Para os campos que usamos f.input, o SimpleForm automaticamente detectou cada tipo de coluna, de modo que o campo "Released on" está renderizado como data e "Discontinued" está renderizado com um checkbox, pois ele representa uma coluna boolean. Sendo uma associação, o campo "Category" foi renderizado como um menu drop down com uma opção em branco. Se você quiser customizar esse campo, pode fazer isso adicionando algumas opções. Por exemplo, podemos remover a opção em branco do "Category" adicionando a opção :include_blank.

/app/view/products/new.html.erb

<%= f.association :category, :include_blank => false %>

O formulário original tem uma lista drop down para o campo rating, mas isso agora foi substituído por um campo texto. Podemos restaurar esse drop down usando a opção :collection passando um range pra ela.

/app/view/products/new.html.erb

<%= f.input :rating, :collection => 1..5 %>

Se queremos a lista renderizada como radio buttons, podemos usar a opção :as.

/app/view/products/new.html.erb

<%= f.input :rating, :collection => 1..5, :as => :radio %>

Quando recarregamos o formulário, vemos que a opção em branco não existe mais no menu drop down e que o campo rating foi renderizado como radio buttons.

Outra grande característica do SimpleForm é detectar automaticamente os campos obrigatórios. Podemos demonstrar isso fazendo os campos name e price obrigatórios no modelo Product.

/app/models/product.rb

class Product < ActiveRecord::Base
  attr_accessible :name, :price, :released_on, :category_id, 
  :rating, :discontinued
  belongs_to :category  
  validates_presence_of :name, :price
end

Isso é tudo que precisamos fazer. Quando recarregarmos o formulário, vamos ver esses campos marcados com asteríscos e se tentarmos submeter o formulário sem preencher esses campos, vamos ver uma mensagem de erro.

Podemos também adicionar um aviso para cada campo. Vamos supor que queremos informar que o preço deve ser dado em libras esterlinas. Só precisamos adicionar uma opção :hint a esse campo.

/apps/views/products/_form.html.erb

<%= f.input :price, :hint => "prices should be in UKP." %>

Isso adicionará uma mensagem informativa depois do campo no formulário.

Há mais informações sobre as opções que podem ser usadas no README do SimpleForm. Vale a pena dar uma olhada no README do Formtastic também, pois muitas opções que ele usa também podem ser usadas pelo SimpleForm.

Personalizando o SimpleForm

Quando executamos o gerador do SimpleForm, ele criou três arquivos.

$ rails g simple_form:install
    create  config/initializers/simple_form.rb
    create  config/locales/simple_form.en.yml
    create  lib/templates/erb/scaffold/_form.html.erb

Se quisermos customizar o SimpleForm em toda a aplicação, podemos modificar esses arquivos. O primeiro contém algumas opções comentadas e muitas configurações podem ser feitas aqui. Por exemplo, podemos alterar a ordem que cada campo é renderizado; podemos alterar a tag html que envolve cada campo e podemos alterar o tamanho padrão de cada campo de texto. Queremos campos de texto mais estreitos na nossa aplicação, então vamos alterar o valor padrão de 50 para 30.

/config/initializers/simple_form.rb

# Use this setup block to configure all options available in SimpleForm.
SimpleForm.setup do |config|

  # Other options removed...

  # Default size for text inputs.
  config.default_input_size = 30
end

Outro arquivo que foi gerado, foi de idiomas e é onde podemos internacionalizar os formulários.

/config/locales/simple_form.en.yml

en:
  simple_form:
    "yes": 'Yes'
    "no": 'No'
    required:
      text: 'required'
      mark: '*'
      # You can uncomment the line below if you need to overwrite the whole required html.
      # When using html, text and mark won't be used.
      # html: '*'
    error_notification:
      default_message: "Some errors were found, please take a look:"
    # Labels and hints examples
    # labels:
    #   password: 'Password'
    #   user:
    #     new:
    #       email: 'E-mail para efetuar o sign in.'
    #     edit:
    #       email: 'E-mail.'
    # hints:
    #   username: 'User name to sign in.'
    #   password: 'No special characters, please.'

Mesmo se a aplicação não precisa mostrar múltiplos idiomas esse arquivo ainda é útil para alterar alguns textos do SimpleForm, como o texto que é apresentado nos campos obrigatórios.

O último arquivo gerado sobrescreve o partial de formulários do gerador do scaffold.

/lib/templates/erb/scaffold/_form.html.erb

<%%= simple_form_for(@<%= singular_name %>) do |f| %>
  <%% if @<%= singular_name %>.errors.any? %>
    <div id="error_explanation">
      <h2><%%= pluralize(@<%= singular_name %>.errors.count, "error") %> prohibited this <%= singular_name %> from being saved:</h2>

      <ul>
      <%% @<%= singular_name %>.errors.full_messages.each do |msg| %>
        <li><%%= msg %></li>
      <%% end %>
      </ul>
    </div>
  <%% end %>

  <div class="inputs">
  <%- attributes.each do |attribute| -%>
    <%%= f.<%= attribute.reference? ? :association : :input %> :<%= attribute.name %> %>
  <%- end -%>
  </div>

  <div class="actions">
    <%%= f.button :submit %>
  </div>
<%% end %>

No Rails 3, podemos sobrescrever qualquer arquivo template de um generator adicionando em nossa aplicação. Então se quisermos customizar o jeito que um generator funciona, para atender a nossa forma de trabalho, podemos simplesmente criar um novo arquivo template.

Por esse episódio é só. O SimpleForm torna fácil criar formulários em suas aplicações Rails e vale muito a pena dar uma olhada nele.

Atualizando para o Rails 3 Parte 3

Tue, 14 Sep 2010 19:54:03 +0000

Neste episódio, vamos terminar nossa série sobre a atualização de uma aplicação Rails 2 para o Rails 3. Fizemos um bom progresso até agora, temos todos os testes da aplicação passando e usamos o plugin de atualização do Rails para encontrar e corrigir a maioria das áreas que necessitam de atualização para o Rails 3. Ainda existem coisas que precisam ser corrigidas nas views e vamos nos concentrar nisso neste episódio.

Removendo Avisos de Código Obsoleto

Antes de começarmos consertando as views, vamos dar outra olhada nos testes. Até o final do último episódio, todos os testes da aplicação estavam passando, mas havia um grande número de avisos de código obsoleto (deprecated) mostrado enquanto executavam. Vamos executar os testes novamente, agora para ver se podemos reduzir o número de avisos.

$ rake spec

# large amount of output snipped.

.DEPRECATION WARNING: error_messages_for was removed from Rails and is now available as a plugin. Please install it with `rails plugin install git://github.com/rails/dynamic_form.git`. (called from _app_views_sponsors__form_html_erb___2363957037552137609_2171491000_4161310651677273387 at /Users/eifion/rails/apps_for_asciicasts/ep227/railscasts/app/views/sponsors/_form.html.erb:2)
...................................................

Finished in 3.24 seconds
152 examples, 0 failures

Os testes continuam passando, mas ainda há um grande número de advertências. Felizmente, a maioria delas são duplicadas então não deve dar muito trabalho retirá-las.

Cortamos a maior parte da saída do rake spec executado acima, mas deixamos o aviso final. Os métodos error_messages_for e error_messages_on estão obsoletos no Rails 3 e podemos substituí-los por um código personalizado que percorre o errors.full_messages para exibir os erros. Os métodos antigos ainda estão disponíveis como um plugin, assim nós vamos tomar o caminho mais fácil e usar esse plugin. As instruções para instalá-lo foram mostradas no aviso acima.

$ rails plugin install git://github.com/rails/dynamic_form.git
Initialized empty Git repository in /Users/eifion/rails/apps_for_asciicasts/ep227/railscasts/vendor/plugins/dynamic_form/.git/
remote: Counting objects: 22, done.
remote: Compressing objects: 100% (17/17), done.
remote: Total 22 (delta 2), reused 0 (delta 0)
Unpacking objects: 100% (22/22), done.
From git://github.com/rails/dynamic_form
 * branch            HEAD       -> FETCH_HEAD

Com o plugin instalado, quando executamos rake spec novamente, o aviso desapareceu. Há outros erros, porém, e um dos que aparecem com frequência é o seguinte:

DEPRECATION WARNING: subclasses is deprecated and will be removed from Rails 3.0 (use descendants instead). (called from block (2 levels) in load_models 
at /Users/eifion/.rvm/gems/ruby-1.9.2-rc2/gems/thinking-sphinx-2.0.0.rc1/lib/thinking_sphinx/context.rb:58)

Esse erro é da biblioteca Thinking Sphinx. Se você estiver recebendo erros de um plugin, vale a pena verificar o issue tracker desse plugin para ver se existem problemas constantes relacionados com o erro que você está vendo. Senão podemos adicionar um e talvez isso seja corrigido para a próxima versão. (Alternativamente, você pode sempre dar fork no código e corrigir o erro você mesmo.)

No caso do Thinking Sphinx, esse problema já foi detectado e corrigido, mas não foi incluído na versão mais recente da gem no momento da escrita desse episódio. Para remover esse aviso de nossa aplicação, podemos dizer ao bundler para obter o código do Thinking Sphinx de um repositório git em vez de uma gem.

Assim, em nossa Gemfile, em vez de incluir Thinking Sphinx da seguinte forma:

/Gemfile

gem 'thinking-sphinx', '>=2.0.0.rc1', :require => 'thinking_sphinx'

vamos incluí-lo assim:

/Gemfile

gem 'thinking-sphinx', :require => 'thinking_sphinx', :git => "git://github.com/freelancing-god/thinking-sphinx.git", :branch => "rails3"

Temos que executar bundle install novamente para que ele baixe o Thinking Sphinx do seu repositório git. Nossa aplicação agora usará essa versão em vez da última gem. Quando rodamos nossos specs novamente, todas passam sem avisos.

$ rake spec
........................................................................................................................................................

Finished in 3.3 seconds
152 examples, 0 failures

Consertando as Views

Com os avisos de código obsoleto resolvidos, podemos nos concentrar nas views. Ao executarmos a aplicação, o primeiro erro que se destaca é a ausência da barra lateral na página de episódios.

Uma parte da página tão grande como essa deve ser coberta por um teste, mesmo que apenas para testar a sua existência. Se fôssemos atualizar essa aplicação para produção, então iríamos escrever um teste para cobrir essa funcionalidade, mas não vamos fazer isso aqui.

Se dermos uma olhada no arquivo de layout, o código que gera a barra lateral é o seguinte:

/app/views/layouts/application.html.erb

<%= yield(:side) || render(:partial => 'shared/side') %>

Esse código irá produzir o conteúdo da barra lateral e se ele retornar nil será renderizado o partial da lateral em seu lugar. O problema aqui é que em versões anteriores do Rails, yield retornava nil se a chamada apropriada ao content_for estivesse faltando na página, enquanto no Rails 3 retorna uma string vazia, então a segunda parte do código nunca será chamada.

Para corrigir isso, podemos usar o content_for? que retorna true se a área de conteúdo foi definida para uma página. Se tiver sido definida, vamos mostrar seu conteúdo, caso contrário vamos usar a barra lateral.

/app/views/layouts/application.html.erb

<%= content_for?(:side) ? yield(:side) : render(:partial=> 'shared/side') %>

Ao recarregar a página agora, a barra lateral é exibida.

Há ainda outros problemas nas views para serem corrigidos. Se formos ver a página de um único episódio, veremos que a exibição das notas está sendo escapada.

O conteúdo para aquela parte da página passa pelo método textilize que é definido no módulo ApplicationHelper.

/app/helpers/application_helper.rb

module ApplicationHelper
  def textilize(text)
    Textilizer.new(text).to_html unless text.blank?
  end
end

Esse método retorna um HTML como uma string. No Rails 3, se você vai passar uma string de HTML para ser exibida em uma view, a string deverá ser marcada como HTML-safe, caso contrário será automaticamente escapada. Para marcar a string como segura, só precisamos chamar o método html_safe para ela.

/app/helpers/application_helper.rb

module ApplicationHelper
  def textilize(text)
    Textilizer.new(text).to_html.html_safe unless text.blank?
  end
end

Agora, a string foi marcada como segura e não será mais escapada. Isso é abordado com mais detalhes no episódio 204 [assistir, ler]. Ao recarregarmos a página novamente a exibição das notas é renderizada corretamente.

Há ainda um pequeno problema nessa página: a barra de título deve incluir o nome do episódio. Esse problema é específico para a forma como os títulos são tratados nessa aplicação. Um método helper title é usado, o qual define uma variável de instância ao invés de usar content_for para definir o título.

/app/helpers/layout_helper.rb

module LayoutHelper
  def title(page_title, show_title = true)
    @content_for_title = page_title.to_s
    @show_title = show_title
  end
end

Para corrigir isso, devemos definir o conteúdo para o título usando content_for, assim:

/app/helpers/layout_helper.rb

module LayoutHelper
  def title(page_title, show_title = true)
    content_for(:title, page_title.to_s)
    @show_title = show_title
  end
end

Agora, quando chamamos yield(:title) no layout, o título será definido corretamente. Podemos passar o conteúdo em si como um bloco ou, como temos aqui, como um segundo argumento.

Corrigindo Links de Destroy

O erro seguinte é na seção de administração da aplicação. Na página a seguir está uma lista de objetos do modelo, cada um com um link edit e destroy.

O problema aqui está com os links destroy. Quando clicamos em um deles, seremos levados para a action show, em vez da action destroy. A razão pela qual a ação de exclusão não é chamada, é que o JavaScript usado para os links destroy foi feito não obstrutivo no Rails 3. Se olharmos no HTML para um dos links, nós vamos ver que o JavaScript não é mais embutido no link destroy. Em vez disso, há dois atributos HTML 5 personalizados que começam com data- e deve haver algum JavaScript que irá detectar esses atributos e alterar a requisição para uma requisição DELETE.

<tr>
  <td>What does the M stand for in MVC?</td>
  <td>model</td>
  <td><a href="/spam_questions/1/edit">Edit</a></td>
  <td><a href="/spam_questions/1" data-confirm="Are you sure?" data-method="delete" rel="nofollow">Destroy</a></td>
</tr>

Como essa aplicação usa jQuery, é preciso baixar o arquivo rails.js personalizado do projeto jquery-UJS. Se estivéssemos usando Prototype, então não teríamos necessidade de fazer isso, pois o arquivo correto já está incluído no diretório /public/javascripts. Fizemos o download do arquivo e copiamos para o diretório javascripts, então vamos precisar adicionar uma referência a ele na tag head do layout. Nós também precisamos adicionar uma meta tag csrf para prevenir ataques cross-site request forgery.

/application/layouts/application.html.erb

<%= javascript_include_tag 'jquery', 'rails', 'application' %>
<%= csrf_meta_tag %>

O uso de JavaScript não obstrutivo no Rails 3 é abordado no episódio 205 [assistir, ler].

Como estamos no arquivo de layout, vamos atualizar a aplicação para usar HTML 5, alterando o DOCTYPE e a tag html.

/application/layouts/application.html.erb

<!DOCTYPE html>
<html>

Existem outras coisas que precisamos fazer para tornar a aplicação totalmente HTML 5. Podemos verificar o código através de um validador para descobrir o que tem que ser mudado.

Com o novo arquivo rails.js no lugar, quando recarregarmos a página Spam Questions, e tentarmos deletar uma das perguntas, a confirmação JavaScript será mostrada e a pergunta será apagada, se clicarmos em OK.

A última alteração que podemos fazer com o código da view é remover todas as chamadas ao método h. Nas views do Rails 2, qualquer saída que precisávamos escapar código HTML tinha que ser tratada com o método h. Todas as saídas no Rails 3 são escapadas por padrão. Então podemos arrumar as views, passando por elas e eliminando esses métodos h. Esse assunto foi coberto no episódio 204 [assistir, ler]. Deixar o método não irá causar quaisquer problemas, mas o código ficará mais limpo sem ele.

Removendo Arquivos Obsoletos

Estamos chegando ao final da atualização agora. Tudo está funcionando, mas precisamos eliminar alguns dos arquivos que não precisamos mais. Quando geramos a nova aplicação Rails 3, foi criada uma nova página de boas-vindas e esta terá que ser removida.

$ rm public/index.html

O mesmo se aplica a imagem do Rails que é mostrada na página de boas-vindas.

$ rm public/images/rails.png

Existem também os arquivos na pasta /script que não são mais usados pelo Rails 3 e podem ser removidos.

$ ls script
about		destroy		process	setup
autospec	generate		rails		setup_test
console	performance	runner	spec
dbconsole	plugin		server	spec_server

Apenas o script rails é usado pelo Rails 3 e assim podemos remover os outros, como console, server e assim por diante.

Isso é tudo para essa série sobre a atualização de uma aplicação Rails 2 para Rails 3. Tenha em mente que muitas coisas que nós cobrimos são específicas para a aplicação Railscasts e não há nenhuma maneira onde nós poderíamos cobrir tudo o que é necessário para atualizar qualquer aplicação para o Rails 3. Se você tiver avisos de código obsoleto ou mensagens de erro, então há chances de que alguém já tenha tido o mesmo problema e uma pesquisa no Google trará a uma solução. Também vale a pena conferir os outros episódios que abrangem Rails 3.

Um grande número de problemas que você vai encontrar quando atualizar uma aplicação será causado por plugins. O site Rails Plugins9 tem uma grande lista de plugins e diz se são compatíveis com o Rails 3 ou não. Se você tiver problemas com um plugin específico, também vale a pena verificar o repositório no Github para ver se há uma versão compatível com Rails 3 disponível.

Atualizando para o Rails 3 Parte 2

Wed, 25 Aug 2010 22:09:38 +0000

No último episódio, nós mostramos como atualizar uma aplicação Rails 2 para Rails 3, usando o site Railscasts como exemplo. Chegamos até a iniciar a aplicação sem erros, mas ainda há algumas coisas que precisamos consertar ou atualizar. Estaremos falando sobre isso aqui

Uma maneira óbvia de ver o que ainda precisa ser consertado é executando os tests ou specs da aplicação. Mas antes vale a pena tomar alguns minutos para olhar a aplicação executando através do navegador, para que possamos detectar erros óbvios. Quando fazemos isso na aplicação do Railscasts, rapidamente descobrimos que enquanto a página de listagem dos episódios funciona, a página de visualização de um episódio lança o seguinte erro:

uninitialized constant ApplicationHelper::Textilizer

Na aplicação, Textilizer é uma classe implementada na pasta /lib. Isso está causando um problema, pois por padrão, no primeiro Release Candidate do Rails 3, os arquivos da pasta /lib não são mais incluídos automaticamente no load path da aplicação. Para consertar isso, podemos fazer o require dos arquivos manualmente ou podemos adicionar essa pasta ao load path.

Vamos escolher a segunda opção e adicionar a pasta ao autoload_paths. Há uma linha comentada no arquivo /config/application.rb que podemos descomentar para fazer isso.

/config/application.rb

# Custom directories with classes and modules you want to be autoloadable.
config.autoload_paths += %W(#{Rails.root}/lib)

A equipe do Rails ainda está trabalhando na melhor maneira de manipular arquivos da pasta /lib, então isso pode mudar para o versão final do Rails 3.

Quando recarregamos a página, temos um erro diferente.

A página agora apresenta um erro relacionado a falta de uma constante APP_CONFIG. Essa constante está definida no arquivo /config/preinitializer.rb.

/config/preinitializer.rb

# load app_config.yml
require 'yaml'
APP_CONFIG = YAML.load(File.read("#{Rails.root}/config/app_config.yml"))

Em uma aplicação Rails 2, esse arquivo é onde colocamos algumas coisas que queremos definir antes da aplicação ser carregada. Nesse caso isso é usado para carregar um arquivo YAML. O arquivo preinitializer.rb não é suportado no Rails 3, então qualquer código dele deve ser movido para o arquivo /config/application.rb. O código do arquivo preinitializer.rb precisa ficar bem no topo desse arquivo, antes da linha require 'rails/all'.

Não podemos simplesmente colar o código como está, pois ele usa o método Rails.root, o qual não está disponível antes do require 'rails/all'. Em vez disso, teremos que fazer referência em relação ao arquivo application.rb.

/config/application.rb

require File.expand_path('../boot', __FILE__)

# load app_config.yml
require 'yaml'
APP_CONFIG = YAML.load(File.read(File.expand_path('../app_config.yml', __FILE__)))

require 'rails/all'

Quando recarregamos a página novamente, ela não parece muito certa. O HTML na seção de notas está sendo "escapado" e a barra lateral direita não foi encontrada. Mas, basicamente, a página carrega e isso é bom o suficiente para uma primeira varredura através da aplicação, pois tudo que estamos fazendo é passar por cada página para ver se alguma exceção aparece. Agora que consertamos as páginas que apresentaram exceções, podemos fazer uma segunda varredura e corrigir erros nas views, como o erro abaixo:

Executando os Testes da Aplicação

Se executarmos rake rails:upgrade:check novamente, veremos que ainda há uma grande lista de coisas para consertar. São principalmente coisas que se tornaram obsoletas (deprecated), que ainda continuam funcionando no Rails 3, mas é improvável que continuem no Rails 3.1. Como as mudanças que precisamos fazer são para coisas obsoletas e não erros, vamos dar uma olhada no conjunto de testes da aplicação e ver se todos os testes passam antes de fazermos alguma alteração no código.

A fim de obtermos os testes executando, precisamos adicionar uma gem ao nosso Gemfile. Só vamos querer que essa gem seja carregada nos ambientes relevantes, então vamos usar o método group para fazer isso. Pode parecer que queremos instalar as gems apenas para o ambiente de testes, mas as gems que incluem tarefas Rake, como RSpec, também terão que ser incluídas no ambiente de desenvolvimento.

A aplicação Railscasts usa Mocha para mocking, juntamente com RSpec e Factory Girl portanto vamos precisar adicionar o seguinte código ao Gemfile.

/Gemfile

group :development, :test do
  gem "mocha"
  gem "rspec-rails", ">= 2.0.0.beta.19"
  gem "factory_girl_rails"
end

Para termos certeza de que essas gems estão instaladas, vamos executar bundle install novamente. Para executarmos o RSpec, precisamos executar seu gerador. O gerador irá substituir os arquivos instalados do RSpec.

$ rails g rspec:install
      create  .rspec
       exist  spec
    conflict  spec/spec_helper.rb
Overwrite /Users/eifion/rails/apps_for_asciicasts/ep226/railscasts/spec/spec_helper.rb? (enter "h" for help) [Ynaqdh] Y
       force  spec/spec_helper.rb
      create  autotest
      create  autotest/discover.rb

O novo arquivo spec_helper.rb precisará sofrer uma pequena alteração antes de continuarmos. Por padrão ele usará o RSpec para mocking, então precisamos atualizar o config.mock_with para usar o Mocha.

A aplicação também tem algumas macros para o RSpec no arquivo /spec/controller_macros.rb e eles precisarão ser incluídos. Mais acima, no arquivo spec_helper, está uma linha que inclui tudo abaixo do diretório support, então tudo que precisamos fazer é criar esse diretório abaixo do spec e mover o arquivo para ele. Agora precisamos adicionar o config.include para incluir nossas macros ao RSpec. Depois dessas alterações, o arquivo vai ficar assim:

/spec/spec/helper.rb

# This file is copied to ~/spec when you run 'ruby script/generate rspec'
# from the project root directory.
ENV["RAILS_ENV"] ||= 'test'
require File.expand_path("../../config/environment", __FILE__)
require 'rspec/rails'

# Requires supporting files with custom matchers and macros, etc,
# in ./support/ and its subdirectories.
Dir["#{File.dirname(__FILE__)}/support/**/*.rb"].each {|f| require f}

RSpec.configure do |config|
  config.mock_with :mocha
  config.fixture_path = "#{::Rails.root}/spec/fixtures"
  config.use_transactional_fixtures = true
  config.include ControllerMacros
end

Agora estamos prontos para executarmos as specs e vermos quantas delas passam. Sabemos que haverá um grande número de advertências de código obsoleto (deprecated), porém no momento estamos procurando apenas testes falhando.

$ rake spec

Esse comando produz uma grande quantidade de mensagens e então mostra que o teste deu um erro. A linha relevante é:

/Users/eifion/rails/apps_for_asciicasts/ep226/railscasts/spec/controllers/episodes_controller_spec.rb:5:in `block in <top (required)>': undefined local variable or method `integrate_views' for :Class (NameError)

Se você tiver mensagens de erro como essa e não souber como resolvê-los, vale a pena pesquisar o erro no Google para ver se alguém já teve o mesmo problema e achou uma solução. Neste caso, a correção é simples. O método integrate_views foi renomeado para render_views e então precisamos mudar isso na aplicação.

Uma vez feito isso podemos executar os specs novamente. Vamos ver mais uma vez uma grande quantidade de mensagens de código obsoleto mas dentre todos os testes apenas quatro falharam.

Finished in 3.53 seconds
152 examples, 4 failures

1) CommentsController as guest index action should render index template for rss with xml
    Failure/Error: response.should have_tag('title', :text => 'Railscasts Comments')
    undefined method `has_tag?' for #<ActionController::TestResponse:0x000001040f2dc8>
    # ./spec/controllers/comments_controller_spec.rb:16:in `block (2 levels) in <main>'

2) EpisodesController as guest index action should render index template for rss with xml
    Failure/Error: response.should have_tag('title', :text => 'Railscasts')
    undefined method `has_tag?' for #<ActionController::TestResponse:0x00000104007710>
    # ./spec/controllers/episodes_controller_spec.rb:26:in `block (2 levels) in <top (required)>'

3) EpisodesController as guest index action should render index template for rss with xml for iPod
    Failure/Error: response.should have_tag('title', :text => /Railscasts.+iPod/)
    undefined method `has_tag?' for #<ActionController::TestResponse:0x00000102e2dd00>
    # ./spec/controllers/episodes_controller_spec.rb:33:in `block (2 levels) in <top (required)>'

4) EpisodesController as guest show action should render show template for rss with xml
    Failure/Error: response.should have_tag('title', :text => /Comments/)
    undefined method `has_tag?' for #<ActionController::TestResponse:0x000001041f03b0>
    # ./spec/controllers/episodes_controller_spec.rb:65:in `block (2 levels) in <top (required)>'

Todas as falhas foram causadas pela mesma coisa: o método have_tag. Novamente uma rápida pesquisa na internet irá ajudar aqui. Podemos verificar que isso está relacionado ao Webrat e que o método have_tag foi removido. Atualmente há um método similar chamado have_selector que pode ser usado no lugar do outro. As opções para o have_selector são um pouco diferentes. Precisamos substituir a opção :text pela :content, por exemplo.

response.should have_tag('title', :text => 'Railscasts')

ficará

response.should have_selector('title', :content => 'Railscasts')

Feito isso, executamos os testes novamente e dessa vez todos passam.

Finished in 3.44 seconds
152 examples, 0 failures

Removendo código obsoleto

Agora que todos os testes passaram, podemos começar a trabalhar com a lista que o rake rails:upgrade:check gera e reduzir a quantidade de mensagens de código obsoleto. O primeiro item da lista é sobre as chamadas do ActiveRecord.

Soon-to-be-deprecated ActiveRecord calls
Methods such as find(:all), find(:first), finds with conditions, and the :joins option will soon be deprecated.
More information: http://m.onkey.org/2010/1/22/active-record-query-interface

Isso se refere a partes do código que usam a antiga sintaxe find, como este método no modelo Episode que leva um hash de condições:

/app/models/episode.rb

def self.primitive_search(query)
  find(:all, :conditions => primitive_search_conditions(query))
end

Nós podemos atualizar códigos como esse usando o novo método where.

/app/models/episode.rb

def self.primitive_search(query)
  where(primitive_search_conditions(query))
end

A nova sintaxe de query do ActiveRecord foi abordada no episódio 202 [assista, leia] então para mais detalhes sobre esse assunto dê uma olhada lá.

O próximo erro na lista é este:

named_scope is now just scope
The named_scope method has been renamed to just scope.
More information: http://github.com/rails/rails/commit/d60bb0a9e4be2ac0a9de9a69041a4ddc2e0cc914

Essa é outra coisa fácil de arrumar. Só precisamos percorrer nossos modelos e substituir qualquer chamada ao método named_scope por scope. Os argumentos também precisarão ser atualizados para usar a nova sintaxe do Rails 3. Por exemplo, no modelo Comment:

/app/models/comment.rb

named_scope :recent, :order => "created_at DESC"

ficará

/app/models/comment.rb

scope :recent, order("created_at DESC")

Note que como vamos percorrendo a aplicação e fazendo essas alterações, devemos manter rodando nossos testes para termos certeza de que nada está sendo quebrado.

O próximo item depois do named_scope são as rotas. O plugin rails upgrade inclui uma tarefa rake para atualizar o arquivo de rotas mas é melhor fazer isso manualmente e aproveitar a oportunidade para limpá-lo.

O arquivo de rotas atualmente está assim:

/config/routes.rb

Railscasts::Application.routes.draw do |map|
  map.resources :spam_questions

  map.resources :spam_checks

  map.with_options :controller => 'info' do |info|
    info.about 'about', :action => 'about'
    info.contest 'contest', :action => 'contest'
    info.feeds 'feeds', :action => 'feeds'
    info.give_back 'give_back', :action => 'give_back'
  end
  
  map.login 'login', :controller => 'sessions', :action => 'new'
  map.logout 'logout', :controller => 'sessions', :action => 'destroy'
  
  map.resources :sponsors
  map.resources :comments
  map.resources :tags
  map.resources :episodes, :collection => { :archive => :get }
  map.resources :sessions
  map.resources :spam_reports, :member => { :confirm => :post }, :collection => { :confirm => :post }
  
  map.root :episodes
end

A nova sintaxe de rotas foi abordada em detalhes no episódio 203 [assista, leia] por isso não vamos falar sobre isso aqui. Após as alterações, o arquivo ficará parecido com isto:

/config/routes.rb

Railscasts::Application.routes.draw do
  root :to => "episodes#index"
  
  match "about" => "info#about", :as => "about"
  match "contest" => "info#contest", :as => "contest"
  match "feeds" => "info#feeds", :as => "feeds"
  match "give_back" => "info#give_back", :as => "give_back"
  match "login" => "sessions#new", :as => "login"
  match "logout" => "sessions#destroy", :as => "logout"
  
  resources :sponsors
  resources :comments
  resources :tags
  resources :episodes do
    collection do
      get :archive
    end
  end
  resources :sessions
  resources :spam_questions
  resources :spam_checks
  resources :spam_reports do
    member do
      post :confirm
    end
    collection do
      post :confirm
    end
  end
end

O novo arquivo de rotas é um pouco maior, mas parece um pouco mais limpo.

Os últimos itens são as chamadas aos helpers ERb obsoletos.

Deprecated ERb helper calls
Block helpers that use concat (e.g., form_for) should use <%= instead of <%.  The current form will continue to work for now, but you will get deprecation warnings since this form will go away in the future.
More information: http://weblog.rubyonrails.org/

No código das views nas aplicações Rails 3 é algumas vezes necessário usar <%= em vez de <% no início dos blocos de saída de conteúdo, como o form_for.

Um exemplo disso está no código do arquivo archive.htmo.erb.

/app/views/episodes/archive.html.erb

<% form_tag archive_episodes_path, :method => 'get' do %>
  <p>
    <%= text_field_tag :search, params[:search] %>
    <%= submit_tag "Search", :name => nil %>
  </p>
<% end %>

O form_tag nesse código vai inserir conteúdo em torno do que está dentro de seu bloco de modo que precisamos modificar isso para usar um sinal de igual.

/app/views/episodes/archive.html.erb

<%= form_tag archive_episodes_path, :method => 'get' do %>

Nem todos os blocos no código das views precisam ser alterados, apesar do rake rails:upgrade:check dizer para fazer isso. Por exemplo, no código abaixo temos uma repetição através de cada item de um hash e não queremos adicionar um sinal de igual, pois o código não adiciona qualquer código em torno do que está dentro do bloco.

/app/views/episodes/archive.html.erb

<% @episode_months.each do |month, episodes| %>
  <h2><%=h month.strftime('%B %Y') %></h2>
  <% for episode in episodes %>
    <div>
      <%= episode.position %>.
      <%= link_to episode.name, episode %>
    </div>
  <% end %>
<% end %>

Mais informações sobre isso disponível no episódio 208 [assista, leia].

Mesmo depois de terminar a correção de todos os códigos das views, o rake rails:upgrade:check ainda mostra erros, porém esses são falsos, pois está indicando todos os blocos em todas as views. Lembre-se de que você só quer mudar as que tem conteúdo de saída, como form_for, form_tag, div_for e assim por diante. Se você está inseguro quanto a saber se um bloco deve ser alterado para usar o sinal de igual, deixe como está e verifique se há avisos de código obsoleto (deprecated) nos testes ou log de desenvolvimento.

Agora que terminamos de usar o plugin upgrade, podemos desinstalar, executando:

$ rails plugin remove rails_upgrade

Nós fizemos um grande progresso na atualização da aplicação para Rails 3. Os testes agora passam e nós removemos todo o código obsoleto. Temos ainda os problemas que vimos anteriormente, onde parte do HTML estava sendo escapado e estava faltando a barra lateral. Nós vamos falar sobre tudo isso no próximo episódio.

Atualizando para o Rails 3 Parte 1

Sun, 08 Aug 2010 19:57:46 +0000

O primeiro release candidate do Rails 3.0 já foi lançado. Esse é um ótimo momento para experimentar o Rails 3, se você já não tiver feito isso, e para ver quais mudanças precisam ser feitas em suas aplicações Rails 2 para atualizá-las. Neste episódio vamos mostrar como atualizar uma aplicação Rails 2.3 para Rails 3.0.

Já existe uma série de episódios sobre Rails 3.0 que você pode assistir ou ler e nós vamos fazer referências a alguns episódios relevantes enquanto trabalhamos com a atualização. A aplicação que vamos começar a atualizar é o site railscasts.com. O código fonte está disponível no Github.

Mesmo se você não estiver pronto para usar Rails 3 em produção, ainda vale a pena tentar atualizar as aplicações Rails 2 só para ver quais problemas você terá que enfrentar. Se suas aplicações usam Git para controle de versão, é fácil criar um branch separado para experimentar. Vamos criar um novo branch chamado rails3.

$ git checkout -b rails3
Switched to a new branch 'rails3'

Antes de começarmos a atualização

Antes de atualizar uma aplicação para o Rails 3, devemos atualizá-la para a última versão do Rails 2.3, que no momento é o Rails 2.3.8. Da mesma forma, qualquer gem que a aplicação usa, deve ser atualizada para a versão mais recente. Desta forma, vamos garantir que não existem problemas de compatibilidade com as versões mais recentes.

Uma vez que tenhamos atualizado o Rails e as gems, devemos executar nossos testes. Ter uma boa suíte de testes automatizados ajudará a garantir que tudo ainda está funcionando como deveria.

$ rake spec
(in /Users/eifion/rails/apps_for_asciicasts/ep225/railscasts)
DEPRECATION WARNING: Rake tasks in vendor/plugins/hoptoad_notifier/tasks 
........................................................................................................................................................

152 examples, 0 failures

Todos os testes passaram. Então estamos prontos para a atualização.

Atualizando o Ruby e Instalando o Rails 3

Para a atualização, queremos utilizar a última versão do Ruby em um ambiente limpo para a aplicação Rails 3, por isso vamos usar o rvm para instalar a última versão do Ruby 1.9.2 e instalar o Rails 3.0. O rvm é atualizado frequentemente, por isso vamos garantir que temos a versão mais recente executando update rvm antes de instalar o Ruby.

$ rvm update

rvm 0.1.40 by Wayne E. Seguin (wayneeseguin@gmail.com) [http://rvm.beginrescueend.com/]

info: fetching rvm-0.1.43.tar.gz

info: Extracting rvm-0.1.43.tar.gz ...

info: Installing rvm-0.1.43...

Uma vez que o rvm está atualizado, precisamos recarregá-lo. Podemos fazer isso, executando:

$ rvm reload

Agora podemos usar o rvm para instalar o Ruby 1.9.2.

$ rvm install 1.9.2

Esse comando irá baixar, compilar e instalar a última versão do Ruby 1.9.2, atualmente em rc2. Quando estiver concluído (pode demorar alguns minutos) poderemos mudar para a nova versão e verificar se ela funciona.

$ rvm 1.9.2
$ ruby -v
ruby 1.9.2dev (2010-07-11 revision 28618) [x86_64-darwin10.4.0]

Agora que sabemos que estamos rodando a versão correta do Ruby, podemos instalar a gem do Rails 3.0 release candidate.

gem install rails --pre

Note que como estamos usando uma versão do Ruby instalada com rvm, não precisamos usar sudo para instalar gems.

Começando a atualização

Agora temos uma nova instalação do Ruby e o Rails 3.0. Então estamos prontos para começar a atualizar nossa aplicação. Para nos ajudar, temos o rails_upgrade plugin, que é um plugin oficial que podemos usar para ver quais alterações precisamos fazer. Para instalar o rails_upgrade, primeiro precisamos voltar para o Rails 2, que está instalado no ambiente do Ruby do sistema.

$ rvm system

Agora podemos instalar o plugin.

$ script/plugin install git://github.com/rails/rails_upgrade.git

Será apresentada uma documentação útil depois da instalação. Um dos principais comandos que ele acrescenta é o rake rails:upgrade:check. Quando executamos esse comando no diretório da nossa aplicação, ele irá mostrar uma lista de tudo que precisa ser atualizado em nossa aplicação. A saída é muito longa para mostrar aqui, mas como exemplo, veremos a primeira parte.

$ rake rails:upgrade:check

(in /Users/eifion/rails/apps_for_asciicasts/ep225/railscasts)
Old router API
The router API has totally changed.
More information: http://yehudakatz.com/2009/12/26/the-rails-3-router-rack-it-up/

The culprits: 
	- config/routes.rb

Antes de começarmos a atualização, vamos executar rake rails:upgrade:backup. Isso irá fazer backup de alguns dos principais arquivos que são suscetíveis de alteração durante a atualização.

$ rake rails:upgrade:backup
(in /Users/eifion/rails/apps_for_asciicasts/ep225/railscasts)
DEPRECATION WARNING: Rake tasks in vendor/plugins/hoptoad_notifier/tasks are deprecated. Use lib/tasks instead. (called from /Library/Ruby/Gems/1.8/gems/rails-2.3.8/lib/tasks/rails.rb:10)

* backing up .gitignore to .gitignore.rails2
* backing up app/controllers/application_controller.rb to app/controllers/application_controller.rb.rails2
* backing up app/helpers/application_helper.rb to app/helpers/application_helper.rb.rails2
* backing up config/routes.rb to config/routes.rb.rails2
* backing up config/environment.rb to config/environment.rb.rails2
* backing up config/environments/development.rb to config/environments/development.rb.rails2
* backing up config/environments/production.rb to config/environments/production.rb.rails2
* backing up config/database.yml to config/database.yml.rails2

This is a list of the files analyzed and backed up (if they existed);
you will probably not want the generator to replace them since
you probably modified them (but now they're safe if you accidentally do!).

- .gitignore
- app/controllers/application_controller.rb
- app/helpers/application_helper.rb
- config/routes.rb
- config/environment.rb
- config/environments/development.rb
- config/environments/production.rb
- config/environments/staging.rb
- config/database.yml
- config.ru
- doc/README_FOR_APP
- test/test_helper.rb

Começaremos a atualizar criando uma nova aplicação Rails 3 no diretório da aplicação. Para fazer isso, é necessário voltar ao ambiente do Ruby 1.9.2.

$ rvm 1.9.2

Agora podemos criar a nova aplicação Rails 3 com:

$ rails new .

Como estamos criando uma nova aplicação no mesmo diretório de uma existente, seremos questionados sobre sobrescrever alguns arquivos existentes. Se não temos certeza se o arquivo deve ser sobrescrito, podemos usar a opção d para ver as diferenças entre o arquivo existente e o que vai sobrescrever.

Nós fizemos backup dos arquivos mais importantes e podemos sobrescrever todos os arquivos conflitantes, exceto esses:

/README
/app/views/layouts/application.html.erb
/public/javascripts/application.js

Os outros arquivos, ou não tiveram mudanças, ou têm backup, nos permitindo refazer quaisquer alterações na nova versão a medida que avançamos.

Nossa aplicação está agora atualizada para o Rails 3.0, mas ainda temos que percorrer os arquivos que fizemos backup e copiar qualquer código que seja específico da nossa aplicação. Cada arquivo que foi feito backup, está em seu diretório original com uma extensão .rails2. Então só precisamos abrir cada arquivo de backup, juntamente com a nova versão, e copiar os códigos que precisam ser mantidos.

Vamos começar com o arquivo de rotas. A sintaxe das rotos mudou, mas a antiga ainda funciona no Rails 3, embora esteja obsoleta (deprecated). Nesse momento podemos apenas copiar as rotas do arquivo de backup para o novo arquivo de rotas e vamos testar isso depois.

Em seguida vamos dar uma olhada no arquivo /config/environment.rb. Corrigir esse arquivo vai dar um pouco mais de trabalho, pois a configuração mudou bastante no Rails 3. O arquivo padrão dos ambientes está bem menor pois as opções de configuração não estão mais lá, foram para o arquivo /config/application.rb.

Existem três coisas no backup do environment.rb que precisamos considerar. A primeira é a configuração do time zone.

config.time_zone = 'Pacific Time (US & Canada)'

Essa linha pode ser movida para o arquivo /config/application.rb.

A segunda parte é o código da sessão.

config.action_controller.session = {
  :session_key => APP_CONFIG['session_key'],
  :secret      => APP_CONFIG['session_secret']
}

No Rails 3 esse código pertence a um arquivo initializer e se olharmos esse arquivo, vamos ver o código para configurar os dados de sessão da aplicação.

/config/initializers/session_store.rb

# Be sure to restart your server when you modify this file.

Railscasts::Application.config.session_store :cookie_store, :key => '_railscasts_session'

# Use the database for sessions instead of the cookie-based default,
# which shouldn't be used to store highly confidential information
# (create the session table with "rake db:sessions:create")
# Railscasts::Application.config.session_store :active_record_store

Podemos deixar esse código como está por enquanto. Vamos alterar isso depois, mas isso não será necessário para ter o site instalado e funcionando.

Finalmente, no final do arquivo de backup do environment.rb está o código de configuração das gems da aplicação.

config.gem "RedCloth", :lib => 'redcloth', :version => ">= 4.0"
config.gem "coderay"
config.gem 'acts-as-list'
config.gem 'will_paginate'
config.gem 'thinking-sphinx', :lib => 'thinking_sphinx'
config.gem 'whenever', :lib => false

Esse código pode ser copiado para o Gemfile, que está no diretório raiz da aplicação. A sintaxe foi ligeiramente modificada e o código precisa ser alterado assim:

/Gemfile

gem "RedCloth", ">=4.0", :require => 'redcloth'
gem "coderay"
gem 'acts-as-list'
gem 'will_paginate'
gem 'thinking-sphinx', :require => 'thinking_sphinx'
gem 'whenever', :require => false

Além de alterar o config.gem para gem em cada linha, há algumas outras alterações que precisamos fazer. O número da versão agora é passado como segundo parâmetro e a opção :lib foi renomeada para :required.

Feito isso, precisamos executar bundle install para ter certeza de que todas as gems necessárias estão instaladas. Para mais informações sobre o bundler e instalação de gems você pode assistir ou ler o episódio 201. Não vamos falar em copiar os códigos dos outros arquivos de backup, mas deve ser bastante simples transferir o código necessário do backup para o novo arquivo.

Com as gems instaladas, vamos tentar iniciar o servidor para ver se a aplicação será iniciada.

$ rails s
/Users/eifion/.rvm/gems/ruby-1.8.7-p299/gems/will_paginate-2.3.14/lib/will_paginate.rb:39:in `enable_activerecord': 
undefined method `returning' for WillPaginate:Module (NoMethodError)
# rest of error truncated…

Não foi. E o motivo foi um erro no código da gem will_paginate, onde temos um método returning indefinido. Esse método estava disponível no Rails 2, mas foi removido no Rails 3.

Em casos como esse, vale a pena chegar o site RubyGems para ver se há disponível uma nova versão da gem em prerelease compatível com o Rails 3. No caso do will_paginate existe e podemos usar, acrescentando o número da versão da gem em nosso Gemfile.

/Gemfile

gem 'will_paginate', '>=3.0.pre'

Se executarmos bundle install novamente, a versão prerelease da gem será instalada e poderemos usar. Agora podemos tentar iniciar o servidor de novo.

$ rails s
/Users/eifion/.rvm/gems/ruby-1.8.7-p299/gems/after_commit-1.0.7/lib/after_commit/active_record.rb:15:in `include_after_commit_extensions': undefined method `subclasses_of' for Object:Class (NoMethodError)
	from /Users/eifion/.rvm/gems/ruby-1.8.7-p299/gems/after_commit-1.0.7/lib/after_commit.rb:81
	from /Users/eifion/.rvm/gems/ruby-1.8.7-p299/gems/thinking-sphinx-1.3.18/lib/thinking_sphinx.rb:2:in `require'
	from /Users/eifion/.rvm/gems/ruby-1.8.7-p299/gems/thinking-sphinx-1.3.18/lib/thinking_sphinx.rb:2

Esse erro parece ter sido causado pela gem Thinking Sphinx. Novamente há uma versão prerelease disponível que podemos usar. Então temos que fazer outra alteração no Gemfile e daí executar o bundle install de novo.

/Gemfile

gem 'thinking-sphinx', '>=2.0.0.rc1', :require => 'thinking_sphinx'

Vamos tentar iniciar o servidor de novo.

$ rails s
DEPRECATION WARNING: railtie_name is deprecated and has no effect. (called from <class:Railtie> at /Users/eifion/.rvm/gems/ruby-1.9.2-rc2/gems/will_paginate-3.0.pre/lib/will_paginate/railtie.rb:6)
=> Booting WEBrick
=> Rails 3.0.0.rc application starting in development on http://0.0.0.0:3000
=> Call with -d to detach
=> Ctrl-C to shutdown server
Exiting
/Users/eifion/rails/apps_for_asciicasts/ep225/railscasts/config/routes.rb:2:in `block in <top (required)>': undefined local variable or method `map' for #<ActionDispatch::Routing::Mapper:0x00000101dffde8> (NameError)

Dessa vez temos algo novo. O servidor tenta iniciar mas reclama sobre uma variável ou método indefinido chamado map nas rotas. Conforme nós colamos o antigo código das rotas no novo arquivo de rotas, estamos usando uma variável map, mas a variável não é passada para o bloco, pois ela não é obrigatória no Rails 3. Nós ainda podemos usar a antiga sintaxe de rotas e passar essa variável.

/config/routes.rb

Railscasts::Application.routes.draw do |map|
  map.resources :spam_questions

  map.resources :spam_checks

  map.with_options :controller => 'info' do |info|
    info.about 'about', :action => 'about'
    info.contest 'contest', :action => 'contest'
    info.feeds 'feeds', :action => 'feeds'
    info.give_back 'give_back', :action => 'give_back'
  end
  
  map.login 'login', :controller => 'sessions', :action => 'new'
  map.logout 'logout', :controller => 'sessions', :action => 'destroy'
  
  map.resources :sponsors
  map.resources :comments
  map.resources :tags
  map.resources :episodes, :collection => { :archive => :get }
  map.resources :sessions
  map.resources :spam_reports, :member => { :confirm => :post }, :collection => { :confirm => :post }
  
  map.root :episodes
end

Quando tentamos iniciar o servidor pela quarta vez, temos sorte e ele inicia sem erros.

$ rails s
DEPRECATION WARNING: railtie_name is deprecated and has no effect. (called from <class:Railtie> at /Users/eifion/.rvm/gems/ruby-1.9.2-rc2/gems/will_paginate-3.0.pre/lib/will_paginate/railtie.rb:6)
=> Booting WEBrick
=> Rails 3.0.0.rc application starting in development on http://0.0.0.0:3000
=> Call with -d to detach
=> Ctrl-C to shutdown server
[2010-08-05 19:30:22] INFO  WEBrick 1.3.1
[2010-08-05 19:30:22] INFO  ruby 1.9.2 (2010-07-11) [x86_64-darwin10.4.0]
[2010-08-05 19:30:22] INFO  WEBrick::HTTPServer#start: pid=9933 port=3000

Se visitarmos a página principal no navegador, vamos ver a página inicial padrão, pois ela foi recriada no diretório /public quando criamos a aplicação Rails 3. Podemos ver nessa página, que o ambiente correto está sendo usado.

Embora tenhamos iniciado o servidor com sucesso, ainda temos muitas coisas que precisamos corrigir, como vemos quando executamos rails:upgrade:check novamente. Também precisamos executar nossas specs de novo para ver se elas passam. Nós vamos fazer isso no próximo episódio.

Controllers no Rails 3

Thu, 05 Aug 2010 21:08:55 +0000

Enquanto as principais mudanças nos controllers do Rails 3 aconteceram nos "bastidores", existem algumas diferenças para os desenvolvedores. Este episódio vai cobrir algumas das novas funcionalidades que foram adicionadas.

Parâmetros no Log

A primeira mudança que vamos mostrar é no ApplicationController. Em uma aplicação Rails 2, você pode filtrar certos parâmetros para não aparecerem em texto simples no arquivo de log, usando o método filter_parameter_logging, como mostrado aqui:

/app/controllers/application_controller.rb

		class ApplicationController < ActionController::Base
	  	protect_from_forgery
	  	filter_parameter_logging :password
		end

Esse método foi substituído (deprecated) no Rails 3 e deve ser removido da sua aplicação. A filtragem de parâmetros está configurada agora no arquivo /config/application.rb. O código que configura os parâmetros que devem ser filtrados está no final do arquivo.

/config/application.rb

# Configure sensitive parameters which will be filtered from the log file.
config.filter_parameters += [:password]

Essa linha é adicionada por padrão nas novas aplicações Rails 3. É fácil esquecer de adicionar filtragem em uma aplicação, então é bom ter essa funcionalidade como padrão. Isso irá, da forma que está, filtrar somente o parâmetro de senha. Será necessário alterar se outro parâmetro, como um número de cartão de crédito, precisar ser filtrado também.

Modos de Redirecionamento

Em seguida vamos dar uma olhada no ProductsController de uma aplicação de loja virtual que tenho escrito. E em como redirecionamentos são tratados quando uma action, como create ou update, é chamada em um controller típico Rails, com os sete métodos habituais RESTful. Se olharmos o código do método create, veremos que depois de validado, o Product foi salvo, a action define uma mensagem flash e então redireciona para a action show do produto recém-criado.

/app/controllers/products_controller.rb

def create
  @product = Product.new(params[:product])
  if @product.save
    flash[:notice] = "Successfully created product."
    redirect_to @product
  else
    render :action => 'new'
  end
end

Esse comportamento é bastante comum em um controller e no Rails 3 podemos combinar essas duas linhas de modo que a mensagem flash torna-se um parâmetro do método redirect_to.

/app/controllers/products_controller.rb

def create
  @product = Product.new(params[:product])
  if @product.save
    redirect_to @product, :notice => "Successfully created product."
  else
    render :action => 'new'
  end
end

As mensagens :notice ou :alert vão funcionar aqui, mas qualquer outro tipo de mensagem flash terá que ser incorporada em um :flash hash. Esse recurso também foi adicionado ao Rails 2.3.6, por isso, se você estiver usando a versão mais recente do Rails 2, então você pode usar esse atalho também.

O método redirect_to acima tem uma instância de um model como parâmetro. Passar um objeto do model Product, como @product, é um atalho para o uso do método product_path(@product). Isso é traduzido para o path da action show desse produto. Se quiséssemos redirecionar para a página de edição, em vez disso, poderíamos usar edit_product_path(@product). Mas existe um outro atalho que podemos usar. Em vez de escrever:

redirect_to edit_product_path(@product)

Poderíamos escrever:

redirect_to [:edit, @product]

Isso será traduzido para o mesmo path da action edit do produto acima, mas com um pouco menos de código. Como o :notice, essa opção acima também funciona na última versão do Rails 2. Esse atalho funciona com recursos aninhados também. Então se um produto pertence a uma categoria, ele pode ser redirecionado com:

redirect_to [@category, @product]

Essa técnica de usar array funciona em qualquer lugar que você precisa gerar uma URL e pode ser usado no código das views em um método link_to, bem como nos controllers.

Cookies Permanentes

O próximo recurso novo que vamos demonstrar são os cookies permanentes. Digamos que quando um usuário cria um novo produto, queremos armazenar o id do produto em um cookie. Podemos usar o método cookies para fazer isso:

/app/controllers/proucts_controller.rb

def create
  @product = Product.new(params[:product])
  if @product.save
    cookies[:last_product_id] = @product.id
    redirect_to @product, :notice => "Successfully created product."
  else
    render :action => 'new'
  end
end

Esse código cria um cookie de sessão que durará apenas enquanto o usuário mantém a sua janela do navegador aberta. Para criar um cookie com uma data de validade explícita no Rails 2, teríamos que transformar o valor em um hash e definir um tempo de validade explícito assim:

cookies[:last_product_id] = { :value => @product_id, :expires => 1.month.from_now }

No Rails 3 (no Rails 2.3.6 e acima), podemos usar o novo método cookies.permanent para criar um cookie com um tempo de vida longo.

cookies.permanent[:last_product_id] = @product.id

Nós também podemos criar cookies assinados dessa forma. Por enquanto não entramos em detalhes sobre isso aqui, mas há um ótimo post no blog do Pratik Naik sobre esse assunto, que merece leitura. Essencialmente podemos usar o método cookies.permanent.signed para gerar um cookie criptografado e lê-lo novamente mais tarde. Note que vamos precisar obter o cookie_verifier_secret em nossa aplicação para isso funcionar.

Usando `respond_with`

A última coisa que vamos mostrar neste episódio é provavelmente a mais significativa mudança nos controller do Rails 3: respond_with. Nós vamos demonstrar isso adicionando um serviço REST sobre uma interface XML para o nosso ProductsController. Isso significa que cada uma das actions do controller terá que devolver uma resposta XML, além de sua resposta padrão HTML.

Em uma aplicação Rails 2, nós implementaríamos isso usando respond_to em cada action, assim:

/app/controllers/products_controller.rb

def index
  @products = Product.all
  respond_to do |format|
    format.html
    format.xml { render :xml => @products }
  end
end

Dentro do bloco respond_to especificamos cada um dos formatos que a action responde, renderizando a versão XML do array de produtos para uma requisição XML. Essa abordagem pode tornar-se incômoda se for necessário fazer isso para cada action de um controller.

No Rails 3, podemos substituir esse código por uma chamada ao método respond_with, passando o objeto apropriado, nesse caso, o array de produtos. Para o respond_with funcionar também precisamos usar o método de classe respond_to para especificar quais tipos MIME o controller deve responder e assim o respond_with sabe o que responder com em cada action.

/app/controllers/products_controller.rb

class ProductsController < ApplicationController
  respond_to :html, :xml
  
  def index
    @products = Product.all
    respond_with @products
    end
  end

  # Other methods
end

Agora que mudamos o nosso ProductsController para usar respond_with, vamos ver se as alterações funcionaram. Se visitarmos a página index de produtos em um navegador, vamos ver a action index com o HTML renderizado como nós esperamos.

E se acrescentarmos .xml à URL, vamos obter a resposta XML.

Como o método respond_with funciona? Para uma simples requisição GET, como index, ele procura, de acordo com o MIME type apropriado, pelo arquivo da view correspondente, como o arquivo .html.erb, e renderiza. Se o respond_with não conseguir encontrar o arquivo da view, então ele vai tentar chamar um método como o to_xml ou o to_json para deixar o objeto que foi passado no formato adequado.

Sabendo disso, podemos atualizar os métodos show e new no ProductsController para usar o respond_with.

/app/controller/products_controller.rb

def show
  @product = Product.find(params[:id])
  respond_with @product
end

def new
  @product = Product.new
  respond_with @product
end

A action create é mais complicada, pois ela tem alguns códigos HTML específicos, como por exemplo, as chamadas para redirect_to e render. Nós não queremos usar esses códigos em uma resposta XML. Podemos contornar o problema removendo-os do método e adicionando uma chamada para respond_with, deixando o método parecido com este:

/app/controllers/products_controller.rb

def create
  @product = Product.new(params[:product])
  if @product.save
    cookies[:last_product_id] = @product.id
    flash[:notice] = "Successfully created product."
  end
  respond_with(@product)
end

Nós podemos fazer isso porque o respond_with irá automaticamente redirecionar ou renderizar, dependendo se o objeto passado para ele é válido. Podemos agora acrescentar respond_with aos outros métodos do controller, removendo qualquer código HTML específico. O código do nosso controller será parecido com este:

/app/controllers/products_controller.rb

class ProductsController < ApplicationController
  respond_to :html, :xml
  
  def index
    @products = Product.all
    respond_with @products
  end
  
  def show
    @product = Product.find(params[:id])
    respond_with @product
  end

  def new
    @product = Product.new
    respond_with @product
  end
  
  def create
    @product = Product.new(params[:product])
    if @product.save
      cookies[:last_product_id] = @product.id
      flash[:notice] = "Successfully created product."
    end
    respond_with(@product)
  end

  def edit
    @product = Product.find(params[:id])
    respond_with(@product)
  end

  def update
    @product = Product.find(params[:id])
    if @product.update_attributes(params[:product])
      flash[:notice] = "Successfully updated product."
    end
    respond_with(@product)
  end
  
  def destroy
    @product = Product.find(params[:id])
    @product.destroy
    flash[:notice] = "Successfully destroyed product."
    respond_with(@product)
  end
end

O método respond_with pode ser um pouco confuso, por isso aqui vai um resumo.

Para uma requisição GET, respond_with procurará primeiro por uma view que responde ao formato específico. Se encontrar irá renderizá-la; caso contrário ele irá chamar to_xml (ou qualquer outro formato que foi solicitado) no objeto que foi passado para ele.

Para qualquer outro tipo de solicitação, respond_with primeiro verifica se o objeto passado tem algum erro. Se isso acontecer, então a view apropriada será renderizada (por exemplo, new para a action create e edit para a action update). Se não houver nenhum erro, então ele irá redirecionar para a página específica do objeto (ou seja, a action show).

Nós podemos testar isso editando um de nossos produtos.

Ao clicar no botão "Update Product" a action update é chamada e respond_with irá executar um redirecionamento para a página do produto.

Da mesma forma, se clicarmos no link "destroy", seremos redirecionados para a página index.

Se o comportamento padrão do respond_with não satisfizer certas necessidades da nossa aplicação, podemos personalizá-lo para determinadas actions. Como um exemplo, digamos que quando atualizarmos um produto, nós queremos o redirecionamento para a action index em vez do padrão que é a action show. Nesse caso, podemos passar a opção de location para o respond_with para que ele redirecione para uma action diferente. Para redirecionar para a página index de produtos em vez de um produto específico da página, podemos alterar a action update da seguinte forma:

/app/controllers/products_controller.rb

def update
  @product = Product.find(params[:id])
  if @product.update_attributes(params[:product])
    flash[:notice] = "Successfully updated product."
  end
  respond_with(@product, :location => products_url)
end

Também podemos substituir formatos específicos passando um bloco para o respond_with, como faríamos com o respond_to. Portanto, se queremos apenas rederizar algum texto para o formato XML da action edit, podemos fazê-lo.

/app/controllers/products_controller.rb

def edit
  @product = Product.find(params[:id])
  respond_with(@product) do |format|
    format.xml { render :text => "I'm XML!" }
  end
end

Quando visitarmos a versão XML da página de edição, vamos ver essa string renderizada.

Finalmente, se precisamos de uma completa personalização, podemos passar uma classe responder personalizada. Dessa forma, o controller irá entregar tudo para a classe e o comportamento da resposta será como gostaríamos.

respond_with(@product, :responder => MyResponder)

Para um exemplo de criação de uma classe responder, dê uma olhada no Responder class do Rails 3. O código é bastante fácil de ler, está bem documentado e você terá uma ideia melhor de como funciona uma resposta.

Por esse episódio, é isso. Como você pode ver o respond_with é uma maneira muito conveniente para lidar com vários formatos. Mas se você estiver personalizando-o muito, poderia ser mais fácil deixar tudo como está e não usá-lo. Alternativamente, se você tem um monte de duplicação, você pode criar sua classe de resposta personalizada.

MongoDB e MongoMapper

Sun, 10 Jan 2010 00:30:06 +0000

MongoDB é um banco de dados baseado em documento, que funciona de forma diferente dos tradicionais bancos de dados relacionais como o MySQL, este tipo de banco não possui schema (schema-free). Este episódio irá cobrir o básico do MongoDb com a gem MongoMapper para criar uma aplicação simples em Rails. Muitos desenvolvedores Rails ouviram falar pela primeira vez sobre MongoDB após uma postagem de John Nunemaker em seu excelente Blog RailsTips mostrando sete características do MongoMapper e MongoDB que contrastam com os tradicionais bancos de dados relacionais. Este post vale a pena ser lido se você pensa que pode estar interessado em usar o MongoDB.

Uma característica mencionada na postagem do blog e que faz o MangoDB interessante é que você não precisa usar migrações, como ele é basicamente um mecanismo(engine) de banco de dados sem esquema, cada linha é seu próprio documento, que pode ter seu próprio conjunto de atributos diferentes das outras colunas no banco de dados. Como não existe um esquema fixo nós podemos definir um se quisermos.

Instalando o MongoMapper e MongoDB

Para criar sua aplicação vamos precisar primeiro instalar o MongoDB. O download para várias plataformas pode ser encontrado na página de download no site do MongoDB. Se você está usando OS X há um grande artigo de como instalar e configurar MongoDB no site do Cris Kampmeir’s. Este artigo inclui um arquivo plist que irá permitir que você crie um LauchDemon para iniciar o MongoDB automaticamente ao iniciar o sistema. O artigo faz referencia a uma versão antiga do MongoDB então tenha certeza que você instalou a última versão (1.2.0 no momento que escrevo isso). Uma vez que o MOngoDB esta instalado e configurado você pode visitar http://localhost:28017/ para ver se ele esta funcionando.

Criando uma aplicação Rails com MongoDB

Agora que nós temos o MongoDb instalado e rodando podemos começar a criar uma app Rails que irá trabalhar com ele. Nós iremos criar uma nova app do zero para este episódio chamada todo.

rails todo

Iremos usar a gem MongoMapper para habilitar à conversa de nossa app com o MongoDB. Para isto nós precisamos adicionar à seguinte linha no bloco config de nosso /config/environment.rb.

/config/environment.rb

config.gem "mongo_mapper"

Nós também precisamos alguma configuração adicional que fazeremos dentro do arquivo initializer. No diretório /config/initializers iremos criar um arquivo chamado mongo_config.rb. Neste arquivo nós apenas precisamos adicionar uma linha para dizer ao MongoMapper qual banco de dados usar.

/config/initializers/mongo_config.rb

MongoMapper.database = "todo-#{Rails.env}"

Ao passar o ambiente atual como parte do nome do banco de dados, vamos criar diferentes bancos de dados para nosso desenvolvimento, ambiente de teste e produção. Se fossemos mover esta aplicação para produção não haveria necessidade de fazer autenticação e assim por diante, mas para propósitos de demonstração esta ótima.

O passo final na configuração de nossa aplicação e rodar o seguinte comando para ter certeza que a gem MongoMapper esta instalada.

sudo rake gems:install

Construindo nossa Aplicação

Agora nós podemos começar a construir nossa aplicação. Esta é uma simples aplicação todo list que terá um modelo Project e cada Project irá ter várias tarefas(Tasks). Para escrever mais facilmente nossa aplicação iremos usar o Nifty Gererators do Rayns Bates, mas essa aplicação pode ser escrita sem ele.

A primeira coisa que vamos fazer é criar um layout para nossa aplicação que podemos fazer rodando:

script/generate nifty_layout

A seguir vamos gerar um model e um scaffold para ele. Project irá ter apenas um campo, nome, e como não estamos gerando um model normal do ActiveRecord iremos passar a opção --skip-migraton para que nenhum arquivo de migração seja gerado.

script/generate nifty_scaffold project name:string --skip-migration

Isto irá gerar um arquivo de model, controller e view para nós. O modelo Project gerado irá usar o ActiveRecord então termos que mudar para ele usar o MongoMapper.

class Project < ActiveRecord::Base  
	attr_accessible :name  
end

Tudo o que temos que fazer aqui é fazer com que a classe pare de herdar de ActiveRecord::Base e inclua o MongoMapper::Document.

Para definir atributos do modelo nós usamos o método key. Passamos o nome do atributo, neste caso, :name. e tambem o tipo que deve ser uma classe Ruby. Para nosso atributo :name sera uma String. Nosso modelo agora se parece com isto.

/app/models/project.rb

	class Project  
	  include MongoMapper::Document  

	  key :name, String  
	end

Com essa mudança fizemos no model nós podemos agora rodar nossa aplicação e usar isto para criar, atualizar e listar os projetos como seria com uma aplicacao baseada em um banco de dados relacional e ActiveRecord, apenas ao invés usando MongoMapper e MongoDB.

Em termos de interface o MongoMapper trabalha de maneira similar ao ActiveRecord. Nós podemos realizar finds e creates, update e destroy nos registro como normalmente fazemos. Ele até suporta validações da mesma maneira como o ActiveRecord, então podemos adicionar:

/app/models/project.rb

	validates_presence_of :name

ao nosso model Project e não permitir mais criar um projeto com o name em branco. Com o MongoMapper há uma maneira melhor para adicionar validações movendo-as para a mesma linha. Para fazer com que o atributo name seja obrigatório podemos adicionar :required => true para os paramêtros do método key.

/app/models/project.rb

	class Project  
	  include MongoMapper::Document  

	  key :name, String, :required => true  
	end

Adicionando mais Atributos

Como o MongoDB é um banco dados sem esquema podemos facilmente adicionar ou alterar atributos no model sem a necessidade de rodar qualquer migração. Se nós quisermos adicionar um atributo priority em nosso Project podemos simplesmente adicionar isto em nosso model.

/app/models/project.rb

	class Project  
	  include MongoMapper::Document  

	  key :name, String, :required => true  
	  key :priority, Integer  
	end

Nós podemos interar com este novo atribuito simplesmente como seria com o ActiveRecord. Então,na partial form de Project podemos adicionar um menu select que irá permitir que nós selecionamos a prioridade quando formos criar ou atualizar um projeto.

/app/views/projects/_form.html.erb

<% form_for @project do |f| %>
  <%= f.error_messages %>
  <p>
    <%= f.label :name %><br />
    <%= f.text_field :name %>
  </p>
  <p>
    <%= f.label :priority %><br />
    <%= f.select :priority, [1,2,3,4,5] %>
  </p>
  <p><%= f.submit "Submit" %></p>
<% end %>

Nós temos que modificar a view show para que possamos mostrar a prioridade de um projeto.

/app/views/projects/show.html.erb

<% title "Project" %>
<p>
  <strong>Name:</strong>
  <%=h @project.name %>
</p>
<p>
  <strong>Priority:</strong>
  <%=h @project.priority %>
</p>
<p>
  <%= link_to "Edit", edit_project_path(@project) %> |
  <%= link_to "Destroy", @project, :confirm => 'Are you sure?', :method => :delete %> |
  <%= link_to "View All", projects_path %>
</p>

Quando nós visitamos a página New Project agora podemos ver um menu select para a prioridade e quando criamos um novo projeto esta prioridade irá ser mostrada.

Como nós criamos um project antes de adicionarmos o atributo priority você pode querer saber qual a prioridade que lhe foi atribuída. Se você olhar nesse projeto verá que a prioridade esta em branco. Como o valor de priority não existe para este documento o MongoDB irá dar valor nulo(nil)

Associações

Em nosso aplicativo Todo nós também queremos ter um model Task(Tarefas); cada Project irá ter muitas Tasks(Tarefas). Iremos gerar um scaffold para isto como fizemos antes para Project. Note que project_id é uma string, nós normalmente usamos um integer.

script/generate nifty_scaffold task project_id:string name:string completed:boolean --skip-migration

No model de Project precisamos modificar o arquivo de modelo para trabalhar com o MongoMapper, substituindo o código especifíco do ActiveRecord

	class Task  
	  include MongoMapper::Document  

	  key :project_id, ObjectId  
	  key :name, String  
	  key :completed, Boolean  

	  belongs_to :project  
	end

Novamente teremos que incluir o MongoMapper::Document e usar o método key para definir os atributos do modelo. Você pode ter esperado que o project_id tivesse o tipo Integer, mas o MongoDB usa ObjectId para armazenar ids.

Definimos o relacionamento de Taks's com Project como seria com o ActiveRecord usando o belongs_to. Em Project você pode esperar usar has_many :tasks, mas para o MongoMapper usamos many.

/app/models/project.rb

	class Project  
	  include MongoMapper::Document  

	  key :name, String, :required => true  
	  key :priority, Integer  

	  many :tasks  
	end

Nós podemos agora rodar o aplicativo e usar o controller e view gerados para criar novas tarefas. Entrar com o id do Project no formulário de tasks será complicado, embora o scaffold gerou um campo de texto para project_id. Isto porque nós definimos ele como uma string quando criamos o scaffold. Vamos modificar a view para que ela use um menu select permitindo à escolha de qualquer Projeto existente. Da mesma forma que seria com um formulário do ActiveRecord podemos usar collection_select para criar um menu select que vai listar todos os projetos.

/app/views/tasks/_form.html.erb

<% form_for @task do |f| %>
  <%= f.error_messages %>
  <p>
    <%= f.label :project_id %><br />
    <%= f.collection_select :project_id, Project.all, :id, :name %>
  </p>

  <!-- Rest of form... -->

Agora tempos um jeito fácil de selecionar um projeto quando estamos criando uma nova tarefa.

Depois que nós termos uma nova tarefa criada, seremos redirecionados para a página dessa tarefa que irá mostrar o id do projeto. Seria melhor se pudéssemos mostrar o nome do Project ao invés do id. Podemos fazer isto substituindo @task.project_id na view show por @task.project.name

/app/views/tasks/show.html.erb

	<% title "Task" %>

	<p>
	  <strong>Project:</strong>
	  <%=h @task.project.name %>
	</p>
	<!-- Rest of form -->

O formulário irá agora mostrar o nome do projeto associado, apenas como seria com o ActiveRecord

Finds no MongoDB

Nós vamos finalizar este episódio mostrando algumas técnicas para usar finds para models Mongo no console. Em alguns casos é muito similar ao ActiveRecord. Por exemplo, podemos procurar todos( find all) projeto com Project.all

>> Project.all
=> [#<Project name: "Yardwork", _id: 4b39d8c9a175750357000001, priority: nil>, #<Project name: "Housework", _id: 4b39fbd1a175750357000002, priority: 3>]

Podemos também procurar um projeto por id...

>> Project.find('4b39d8c9a175750357000001')
=> #<Project name: "Yardwork", _id: 4b39d8c9a175750357000001, priority: nil>

... ou fornecer opções para procurar todos os registros em uma dada ordem.

>> Project.all(:order => "name DESC")
=> [#<Project name: "Yardwork", _id: 4b39d8c9a175750357000001, priority: nil>, #<Project name: "Housework", _id: 4b39fbd1a175750357000002, priority: 3>]

Como o ActiveRecord nós podemos passar condições para o find. Este difere do ActiveRecord em que as condições são passadas inline então nós irímos procurar todos os projetos com prioridade 3:

>> Project.all(:priority => 3)
=> [#<Project name: "Housework", _id: 4b39fbd1a175750357000002, priority: 3>]

E sobre as condições mais complexas? Como o Mongo não é baseado em SQL não podemos simplesmente passar uma string SQL para a condição. Ao invés ele tem sua própria linguagem para criar condições mais complexas. MongoMapper fornece um jeito conveniente para contornar isto passando um método para um símbolo . Por exemplo, para pegar todos os projetos que tenham prioridade de dois ou mais, podemos fazer:

>> Project.all(:priority.gte => 2)
=> [#<Project name: "Housework", _id: 4b39fbd1a175750357000002, priority: 3>]

Nós podemos também usar in, passando um array de valores para o find, dizendo, projetos com a prioridade 2 ou 3.

>> Project.all(:priority.in => [2,3])
=> [#<Project name: "Housework", _id: 4b39fbd1a175750357000002, priority: 3>]

A Documentação é um pouco escassa sobre condições no momento, mas você pode descobrir mais sobre eles através da leitura do arquivo de test no github. Isto é tudo por esse episódio. Nós apenas cobrimos o básico do MongoDB e MongoMapper então você esta encorajado a fazer sua própria pesquisa se quiser continuar. A uma maillgin list você pode se juntar a ela e você pode seguir o MongoDB no Twiiter.

A grande questão que você precisa fazer para si mesmo é, devo usar MongoDb ao invés de um tradicional bando de dados relacional? Isto realmente cabe a você pensar e decidir se o MongoDB é apropriado para seu Projeto Rails. Mas você esta incentivado a dar uma chance para ver se ele se ajusta ao seu projeto. Em termos mais longos parece que os bancos de dados baseados em documentos irão desempenhar um grande papel na construção de aplicações Rails.

ASCIIcasts - Full Episode Feed

Gravatar

Customizando imagens do Gravatar

Usando imagens de outros sites com OmniAuth

Beanstalkd e Stalker

Começando com Beanstalkd

Usando o Beanstalk em uma aplicação Rails

Otimizando o processo em segundo plano

Tratamento de Erros

Persistindo Beanstalk

Mongoid

Instalando o MongoDB

Criando uma nova aplicação Rails utilizando o Mongoid

Adicionando campos

Validações

Associações

Tipo de associações de referências

Usando attr_accessible dinamicamente.

Nosso Wiki Site

SimpleForm

Integrando SimpleForm em uma Aplicação

Personalizando Campos

Personalizando o SimpleForm

Atualizando para o Rails 3 Parte 3

Removendo Avisos de Código Obsoleto

Consertando as Views

Corrigindo Links de Destroy

Removendo Arquivos Obsoletos

Atualizando para o Rails 3 Parte 2

Executando os Testes da Aplicação

Removendo código obsoleto

Atualizando para o Rails 3 Parte 1

Antes de começarmos a atualização

Atualizando o Ruby e Instalando o Rails 3

Começando a atualização

Controllers no Rails 3

Parâmetros no Log

Modos de Redirecionamento

Cookies Permanentes

Usando respond_with

MongoDB e MongoMapper

Instalando o MongoMapper e MongoDB

Criando uma aplicação Rails com MongoDB

Construindo nossa Aplicação

Adicionando mais Atributos

Associações

Finds no MongoDB

Usando `respond_with`