What namespace :admin do ... end generates
What namespace :admin do ... end generates
This app's config/routes.rb opens its admin section with:
namespace :admin do
root to: "dashboard#show"
namespace :catalog do
resources :courses
# ...
end
# ...
end
Controller filters & concerns, the course before this one, showed Admin::Catalog::CoursesController < Admin::BaseController, a nested module. That nesting isn't a coincidence, and it isn't something each controller file decides on its own: namespace :admin do ... end, in routes.rb, is what Rails expects it to match.
The routes, from 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
This is this app's bin/rails routes output for those lines. Every URL under this namespace, /admin, /admin/catalog/courses, /admin/identity/users, starts with /admin. Every controller Rails looks for, admin/dashboard#show, admin/catalog/courses#index, starts with the admin/ directory and the Admin:: module.
The convention in that block: path prefix and controller module
namespace :admin do ... end does two things to everything written inside it. It prefixes every generated URL with /admin, and it expects every controller referenced inside it to live in the Admin:: module (and, by Rails' file-naming convention, in app/controllers/admin/). resources :courses, written inside namespace :admin do namespace :catalog do ... end end, never says Admin::Catalog::CoursesController: the two namespace blocks around it say it, and Rails looks there.
Namespacing and the guard from the previous course
Admin::BaseController, from the previous course, is what nearly every controller in app/controllers/admin/ inherits from: Admin::Catalog::CoursesController, Admin::Identity::UsersController, Admin::Partners::PartnersController and the rest. The exceptions are the two reorder controllers, which inherit from ApplicationController and declare before_action :require_admin themselves (lesson 5). Namespacing controls where a controller lives, in the URL and on disk; inheritance controls what runs before its action. namespace :admin do ... end is why these controllers live under Admin::; Admin::BaseController is why most of them require login and admin access before their own code runs. They're two separate mechanisms applied to the same files.
What this course covers
Seven lessons, each checked against this app's config/routes.rb, its bin/rails routes output and the controller files the routes point to. This lesson covers the hook. Lesson 2 nests one namespace inside another, admin then catalog, and shows the URL and the controller module growing one level at a time. Lesson 3 covers the module: option, which routes to a controller in a subdirectory without adding a URL segment. Lesson 4 combines module: with a shallow nested resource, this app's sharpest split between URL shape and controller module. Lesson 5 covers to: "path/to#action", a fully explicit third way to route, with no namespace or module: at all. Lesson 6 covers a triple-nested namespace, execution, then api, then v1. Lesson 7 ends with a challenge that simulates the path-resolution rule in plain Ruby.
Keep going with lesson 2
Nesting namespaces: admin, then catalog, inside it
Nests catalog inside admin, adding one URL segment and one controller module level per namespace block.
A free account also gives you the quizzes, your progress and notes, and the discussion.