What namespace :admin do ... end generates

Free preview 3 min to read

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.

Lesson 1 of 7 · free

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.

Type to start searching...