O que namespace :admin do ... end gera

Prévia grátis 3 min de leitura

O que namespace :admin do ... end gera

O config/routes.rb deste app abre a seção de admin com:

namespace :admin do
  root to: "dashboard#show"
  namespace :catalog do
    resources :courses
    # ...
  end
  # ...
end

Filtros e concerns, o curso anterior, mostrou Admin::Catalog::CoursesController < Admin::BaseController, um módulo aninhado. Esse aninhamento não é coincidência, e não é algo que cada arquivo de controller decide sozinho: o namespace :admin do ... end, no routes.rb, é o que o Rails espera que ele acompanhe.

As rotas, do bin/rails routes

admin_root       GET  /admin                    admin/dashboard#show
admin_catalog_courses  GET  /admin/catalog/courses    admin/catalog/courses#index
admin_identity_users   GET  /admin/identity/users     admin/identity/users#index
admin_partners_partners GET /admin/partners/partners  admin/partners/partners#index

Esta é a saída de bin/rails routes deste app para essas linhas. Toda URL neste namespace, /admin, /admin/catalog/courses, /admin/identity/users, começa com /admin. Todo controller que o Rails procura, admin/dashboard#show, admin/catalog/courses#index, começa com o diretório admin/ e o módulo Admin::.

A convenção do bloco: prefixo de caminho e módulo do controller

O namespace :admin do ... end faz duas coisas com tudo o que é escrito dentro dele. Põe o prefixo /admin em toda URL gerada, e espera que todo controller citado dentro dele viva no módulo Admin:: (e, pela convenção de nomes de arquivo do Rails, em app/controllers/admin/). resources :courses, escrito dentro de namespace :admin do namespace :catalog do ... end end, nunca diz Admin::Catalog::CoursesController: os dois blocos namespace em volta dizem, e o Rails procura lá.

Namespace e a proteção do curso anterior

O Admin::BaseController, do curso anterior, é de quem quase todo controller em app/controllers/admin/ herda: Admin::Catalog::CoursesController, Admin::Identity::UsersController, Admin::Partners::PartnersController e os demais. As exceções são os dois controllers de reordenação, que herdam de ApplicationController e declaram before_action :require_admin por conta própria (aula 5). O namespace controla onde um controller vive, na URL e no disco; a herança controla o que roda antes da ação dele. O namespace :admin do ... end é o motivo de esses controllers viverem em Admin::; o Admin::BaseController é o motivo de a maioria exigir login e acesso de admin antes de o próprio código rodar. São dois mecanismos separados aplicados aos mesmos arquivos.

O que este curso cobre

Sete aulas, cada uma conferida no config/routes.rb deste app, na saída do bin/rails routes e nos arquivos de controller para os quais as rotas apontam. Esta aula trata do gancho. A aula 2 aninha um namespace dentro de outro, admin e depois catalog, e mostra a URL e o módulo do controller crescendo um nível por vez. A aula 3 trata da opção module:, que leva a um controller num subdiretório sem acrescentar segmento à URL. A aula 4 junta module: com um recurso aninhado raso, a separação mais forte deste app entre o formato da URL e o módulo do controller. A aula 5 trata de to: "caminho/do#action", uma terceira forma, totalmente explícita, de rotear, sem namespace nem module:. A aula 6 trata de um namespace com três níveis, execution, depois api, depois v1. A aula 7 fecha com um desafio que simula em Ruby puro a regra de resolução de caminho.

Aula 1 de 7 · grátis

Continue com a aula 2

Aninhando namespaces: admin, depois catalog, dentro dele

Aninha catalog dentro de admin, somando um segmento de URL e um nível de módulo por bloco.

Com uma conta grátis você também tem os quizzes, seu progresso e suas anotações, e a discussão.

Digite para buscar...