Se você tem o costume de evitar repetições em suas views criando helpers, com certeza já usou o método concat. Se você nunca usou este método, saiba que ele é como o puts para uma view.
A implementação atual do método recebe dois parâmetros, uma string com o texto que será exibido na view e um segundo chamado binding. Acontece que devido a melhoria no código, embora ele ainda espere estes dois parâmetros, o binding não é mais necessário, na verdade o método simplesmente não o usa mais.
Então este segundo parâmetro foi deprecado, ou seja, se você estiver informando ele à chamada do método e rodando o edge rails, receberá a seguinte mensagem ao subir o seu servidor:
The binding argument of #concat is no longer needed. Please remove it from your views and helpers.
Em uma futura versão do Rails, este segundo parâmetro será removido.
Um novo método foi adicionado ao módulo Enumerable: many?. E como o nome mesmo diz, ele verifica se a coleção possui mais de um objeto, ou em outras palavras se tem muitos objetos associados.
Este método é um alias para collection.size > 1. Vamos ver alguns exemplos:
>> [].many?
# => false
>> [ 1 ].many?
# => false
>> [ 1, 2 ].many?
# => true
É engraçado, mas o DHH parece que gosta destas coisinhas. Toda vez que aparece algo assim, pode ter certeza que ele está envolvido.
P.S.: Só uma curiosidade, o método deveria se chamar several?, mas foi alterado depois para many?.
Um novo método foi acrescentado à classe Object. O método present? é o equivalente a !Object#blank?.
Em outras palavras um objeto está presente se ele não for vazio. Mas o que é um objeto vazio?
true; end
end
a = EmptyTrue.new
b = nil
c = false
d = ''
e = ' '
g = " \n\t \r "
g = []
h = {}
a.present? # => false
b.present? # => false
c.present? # => false
d.present? # => false
e.present? # => false
f.present? # => false
g.present? # => false
h.present? # => false
Todos estes objetos são vazios ou não estão presentes.
Mas, muito cuidado, algumas pessoas tem confundido as coisas. Veja alguns exemplos de objetos que NÃO estão vazios, ou seja, estão presentes:
false; end
end
a = EmptyFalse.new
b = Object.new
c = true
d = 0
e = 1
f = 'a'
g = [nil]
h = {nil => 0 }
a.present? # => true
b.present? # => true
c.present? # => true
d.present? # => true
e.present? # => true
f.present? # => true
g.present? # => true
h.present? # => true
Qualquer objeto que contenha um valor, está presente, isto vale até mesmo para um Array preenchido com um nil, porque o Array não está vazio.
No Rails 2.1, gems passaram a poder ser usadas como plugins em nossos projetos. Para isto bastava criar uma pasta chamada rails dentro do projeto do gem e incluir um arquivo init.rb.
Isto acrescentou um leque de novidades como config.gem e rake:gems. Mas isto nos faz pensar, já que agora eu posso carregar gems dentro da minha aplicação Rails, seria apenas uma questão de tempo até que plugins deixassem de existir.
E parece que isto realmente pode acontecer. No edge rails, por exemplo, foi incluída uma alteração que permite inicializar plugins tanto pelo arquivo init.rb na raiz do plugin, como em um arquivo em um diretório rails/init.rb (da mesma forma como fazemos com os gems), sendo esta segunda opção a prioritária.
Assim, eu poderia por exemplo criar um gem (que funcionaria como um plugin) e instalar de duas maneiras:
./script/plugin install git://github.com/user/plugin.git
sudo gem install user-plugin --source=http://gems.github.com
Isto sem precisar manter dois arquivos init.rb (um na raiz e outro no diretório rails).
Hoje de manhã eu falei desta nova classe no Rails, e comentei que estavam querendo mudar o seu nome. Pois bem, isto aconteceu mesmo!
Agora a classe se chama StringInquirer. Além disso ela também foi incluída no namespace ActiveSupport.
Vejam o mesmo exemplo usado no artigo anterior, mas adaptado para funcionar com estas alterações:
ActiveSupport::StringInquirer.new("ativo")
end
end
c = Cliente.new
c.status
# => "ativo"
# Agora vem a grande diferença:
c.status.ativo?
# => true
c.status.inativo?
# => false
David acabou de incluir uma novidade interessante no Rails, a classe StringQuestioneer (alguns estão tentando mudar este nome para StringInquirer, mas por enquanto é StringQuestioneer mesmo).
Para entender como funciona, vou ter de explicar usando alguns exemplos. Vamos criar uma classe chamada Cliente que contém um método que retorna o status do cliente:
"ativo"
end
end
c = Cliente.new
c.status
# => "ativo"
c.status == "ativo"
# => true
c.status == "inativo"
# => false
Ok, até aqui tudo normal. Agora vou modificar a implementação do método status usando a classe StringQuestioneer, sempre lembrando que o retorno do método status pode vir de uma coluna do banco de dados (claro), isto é apenas um exemplo.
StringQuestioneer.new("ativo")
end
end
c = Cliente.new
c.status
# => "ativo"
# Agora vem a grande diferença:
c.status.ativo?
# => true
c.status.inativo?
# => false
Para verificar se o status do cliente é o esperado, ao invés de comparar Strings, eu uso um método com o valor do status e o sinal de interrogação. Gostou?
Claro que isto já começou a ser usado no próprio Rails. Por exemplo, caso você precise verificar se o Rails foi carregado em ambiente de produção, você pode substituir o velho Rails.env == “production”, por:
Rails.env.production?
Para variar criei mais um plugin só para ir colocando as novidades que gostei e não quero esperar
para usar. Para quem quiser acompanhar, tá no GitHub (para variar):
http://github.com/carlosbrando/back-to-the-future
Mais um patch do José Valim (desta vez eu prestei atenção de quem era).
Ele adicionou a opção :layout no método caches_action.
end
No exemplo acima eu especifiquei :layout => false, isto significa que o layout não será armazenado no cache, apenas o conteúdo da action será. Isto é muito útil quando temos conteúdo dinâmico no layout (o que acontece na maioria dos casos).
Se você não especificar nada ele assumirá o padrão atual que é true.
Antes de qualquer coisa, me deixe explicar como ficaram organizadas as coisas aqui no blog. A série Edge Rails, como sempre, continua tratando das versões futuras do Rails. Para ver todos os posts da série, você pode usar a categoria Edge Rails. Mas, para relembrar tudo que foi escrito antes do lançamento do Rails 2.1, criei uma categoria com o mesmo nome para facilitar, e movi todos os posts antigos para ela.
Outra coisa importante é que já está saindo do forno o livro sobre Ruby on Rails 2.1 e será disponibilizado em PDF (de grátis!!!) em breve. Aliás, se alguém bom com Photoshop estiver lendo este post e estiver a fim de ajudar com uma capa bem bonita para o livro, entre em contato comigo, por favor!
Ok, agora vamos ao que interessa:
O método reload foi incluído ao ActionView::Helpers::PrototypeHelper para ser usado em templates .rjs ou blocos render(:update). Este método força a recarga da página atual no browser usando javascript. Em outras palavras é um atalho para o já muito usado window.location.reload();.
Veja como usar:
respond_to do |format|
format.js do
render(:update) {|page| page.reload }
end
end
Nem bem saiu o Rails 2.1 e já foi encontrado um erro sério. Entre no irb e tente rodar isto:
Date.new(2008, 5, 31).end_of_quarter
ERRO!
Por que? A implementação do método end_of_quarter foi feita da maneira errada, ele avança até o último mês do trimestre e depois pega último dia. O problema é que ele apenas avança o mês, e como estou partindo do dia 31 de maio, ele tentar criar uma nova instância do objeto Date para 31 de junho, que não existe. Com o objeto Time não é disparado uma exceção, mas ele retorna a data errada: 31 de julho.
No Edge Rails isto já foi corrigido, mas quem estiver usando o Rails 2.1 vai ter este problema.
Muito cuidado, porque este erro só ocorrerá se usarmos o método end_of_quarter nos dias 31 de maio, julho e agosto. Então… muito cuidado.
Para quem não gosta de viver perigosamente usando o edge rails, e também não quer deixar sua aplicação com um erro que pode aparecer de uma hora para a outra, eu criei um plugin com o código que corrige o bug. Na verdade, toda vez que alguma correção sair vou tentar manter este plugin atualizado.
Para instalar:
./script/plugin install git://github.com/carlosbrando/rails21_fixes.git
Gostou? Que tal me recomendar no WWR. É só clicar aqui e pronto!