Tradução: Trazendo provides/display do Merb para o Rails 3

by Ricardo Yasuda on December 29, 2008 21:23

A essa altura todos já sabem sobre a fusão de Rails e Merb, então não me dar ao trabalho de noticiar ou comentar.

O interessante agora vai ser ver exatamente o que de bom do Merb que o Rails vai ter na versão 3. O DHH já postou uma das mudanças e eu traduzo abaixo:

Trazendo provides/display do Merb para o Rails 3

O fluxo de idéias do Merb para o Rails 3 já está caminhando. Deixe-me mostrar um dos primeiros exemplos que estive trabalhando no design. Merb tem uma feature relacionada à estrutura do respond_to do Rails que funciona para os casos genéricos onde você tem um objeto ou coleção que você gostaria de servir em diferentes formatos. Aqui está um exemplo:

class Users < Application

provides :xml, :json def index @users = User.all display @users end

end

Este controller pode responder a requisições html, xml e json. Quando display for executado, ele primeiro checará se existe um template disponível para o tipo requisitado, o que é normalmente o caso com HTML, e caso contrário tentará converter o objeto. Então @users.to_xml como resultado de uma requisição XML.

As aplicações em que eu trabalhei nunca tiveram realmente este caso, no entanto. Sempre tive que fazer mais do que apenas converter o objeto para o tipo ou renderizar um template. Ou eu precisava fazer um redirecionamento para um dos tipos em vez de renderizar ou eu precisava fazer outra coisa além de renderizar. Então eu nunca passei muito tempo com o caso default que já vem com os scaffolds:

class PostsController < ApplicationController

def index @posts = Post.find(:all) respond_to do |format| format.html format.xml { render :xml => @posts } end end def show @post = Post.find(params[:id]) respond_to do |format| format.html format.xml { render :xml => @post } end end

end

Corte duplicação quando possível, dê controle total quando não

Mas o caso da duplicação é definitivamente real para algumas classes de aplicações. E isso é muito feio. Os blocos respond_to se repetem para index, show e geralmente mesmo no edit. Isso é três vezes uma estrutura razoavelmente peso-pesada. Este é o caso em que provides/display vem a calhar e elimina a duplicação.

Para o Rails 3, nós queremos o melhor dos dois mundos. A estrutura completa do respond_to quando você precisa fazer coisas que não estavam na estrutura genérica, mas ainda ter a abordagem genérica na manga para quando as circunstâncias estiverem disponíveis para seu uso.

Lidando com simetria e expansão progressiva do design da API

Há algumas desvantagens na dupla provides/display, porém, que gostaríamos de lidar ao mesmo tempo. A primeira é a falta de simetria nos nomes dos métodos. As palavras “provides” e “display” não refletem o seu relacionamento próximo e se você ainda levar em conta o fato que eles estão realmente relacionados à renderização, a coisa fica ainda mais feia.

A simetria se relaciona com outro ponto no design da API que estive interessado ultimamente: expansão progressiva. Deveria haver um caminho suave do caso simples para o caso complexo. Deveria ser como um Ogro, ele deve ter camadas. Aqui está o resultado que chegamos:

class PostsController < ApplicationController
respond_to :html, :xml, :json

def index @posts = Post.find(:all) respond_with(@posts) end def show @post = Post.find(params[:id]) respond_with(@post) end

end

Esse é o exemplo padrão de provides/display, mas ele tem a simetria no respond_to como método de classe, respond_with como método de instância, e os blocos originais respond_to. Então ele também parece progressivo quando você abre o respond_with e o transforma em um respond_to completo se você repentinamente precisa de diferenças por formato.

O design também estende o estilo de trabalhar somente em nível de instância sem os default de nível de classe:

class DealsController < SubjectsController

def index @deals = Deal.all respond_with(@deals, :to => [ :html, :xml, :json, :atom ]) end def new respond_with(Deal.new, :to => [ :html, :xml ]) end

end

É bastante frequente que a action index tenha responsabilidades de formato diferentes do new ou do show ou de qualquer outra coisa. Esse design aborda todos esses cenários.

Yehuda também esteve interessado em melhorar a performance do respond_to/with ao eliminar os blocos necessários. Especialmente quando você está apenas usando respond_with que não precisa declarar bloco algum.

Levando em conta tudo isso, acho que este é um grande exemplo to tipo de funcionalidade superior que pode sair de idéias misturadas dos dois lados. Estamos certamente animados em fazer o mesmo truque em vários outros elementos do framework. Tenho explorado como um roteador revisado que importa as melhores idéias de ambos poderia ser. Escreverei sobre isso quando tiver algo real para compartilhar.