A herança de visão (às vezes chamada de herança de template) é um bom recurso de Rails / ActionController que parece ser freqüentemente negligenciado, mal compreendido ou ignorado como não sendo útil – mas quando usado corretamente pode realmente ajudar a DRY e organizar suas visualizações.
A forma como funciona é bastante simples: ao verificar o sistema de arquivos por um template ou parcial, Rails irá subir na hierarquia de herança do controlador até encontrar algo. Por exemplo, considere o seguinte:
class AuthenticatedController < ApplicationController
before_filter :authenticate_user!
end
class UsersController < AuthenticatedController
# some awesome code...
end
Ao renderizar um parcial – digamos _table.html.erb
, o sistema de arquivos será verificado na seguinte ordem:
app/views/users/_table.html.erb
app/views/authenticated/_table.html.erb
app/views/application/_table.html.erb
O primeiro arquivo encontrado será usado. O mesmo vale para modelos (como index.html.erb
).
Tudo vai bem até que você se encontre em uma situação em que a herança direta não faça sentido. Se você fez uso do concerns
diretório e abstraiu pedaços de código de controlador reutilizável (bom trabalho) – efetivamente herança múltipla – você perceberá que perdeu a funcionalidade acima.
O culpado é o #parent_prefixes
método, que recorre a hierarquia de herança usando #superclass
. Não tema – é fácil mexer com:
# app/controllers/concerns/authenticating_controller.rb
module AuthenticatingController
extend ActiveSupport::Concern
included do
before_filter :authenticate_user!
end
module ClassMethods
def parent_prefixes
@parent_prefixes ||= super.unshift('authenticated')
end
end
end
module UsersController < ApplicationController
include AuthenticatingController
# the same awesome code...
end
Devo mencionar que parece que esse método de sobrescrever #parent_prefixes
está programado para o bloco de corte – ele será substituído #local_prefixes
no Rails 4.3 e 5.0.