różnica między zakresem i przestrzenią nazw routingu ruby-on-rails 3

Nie mogę zrozumieć, jaka jest różnica między przestrzenią nazw a zakresem w routingu ruby-on-rails 3.

Czy mógłby ktoś wyjaśnić?

namespace "admin" do
  resources :posts, :comments
end

scope :module => "admin" do
  resources :posts, :comments
end

Różnica polega na generowanych ścieżkach.

Ścieżki są admin_posts_pathi admin_comments_pathdla przestrzeni nazw, podczas gdy są sprawiedliwe posts_pathi comments_pathdla zakresu.

Możesz uzyskać ten sam wynik, co przestrzeń nazw, przekazując :name_prefixopcję do zakresu.

przykłady zawsze mi pomagają, więc oto przykład:

namespace :blog do
  resources :contexts
end

poda nam następujące trasy:

    blog_contexts GET    /blog/contexts(.:format)          {:action=>"index", :controller=>"blog/contexts"}
                  POST   /blog/contexts(.:format)          {:action=>"create", :controller=>"blog/contexts"}
 new_blog_context GET    /blog/contexts/new(.:format)      {:action=>"new", :controller=>"blog/contexts"}
edit_blog_context GET    /blog/contexts/:id/edit(.:format) {:action=>"edit", :controller=>"blog/contexts"}
     blog_context GET    /blog/contexts/:id(.:format)      {:action=>"show", :controller=>"blog/contexts"}
                  PUT    /blog/contexts/:id(.:format)      {:action=>"update", :controller=>"blog/contexts"}
                  DELETE /blog/contexts/:id(.:format)      {:action=>"destroy", :controller=>"blog/contexts"}

Korzystanie z zakresu ...

scope :module => 'blog' do
  resources :contexts
end

Da nam:

     contexts GET    /contexts(.:format)           {:action=>"index", :controller=>"blog/contexts"}
              POST   /contexts(.:format)           {:action=>"create", :controller=>"blog/contexts"}
  new_context GET    /contexts/new(.:format)       {:action=>"new", :controller=>"blog/contexts"}
 edit_context GET    /contexts/:id/edit(.:format)  {:action=>"edit", :controller=>"blog/contexts"}
      context GET    /contexts/:id(.:format)       {:action=>"show", :controller=>"blog/contexts"}
              PUT    /contexts/:id(.:format)       {:action=>"update", :controller=>"blog/contexts"}
              DELETE /contexts/:id(.:format)       {:action=>"destroy", :controller=>"blog/contexts"}

Oto dobra lektura na ten temat: http://edgeguides.rubyonrails.org/routing.html#controller-namespaces-and-routing

z prowadnicy szyn

„Zakres przestrzeni nazw zostanie automatycznie dodany, :asa także :modulei :pathprzedrostki”.

więc

namespace "admin" do
  resources :contexts
end

jest taki sam jak

scope "/admin", as: "admin", module: "admin" do
  resources :contexts
end

Zarówno zakres i nazw są scoping zestaw tras do danej opcji domyślnych.
Tyle tylko, że nie istnieją żadne opcje domyślne dla zakresu , a do nazw :path , :as, :module, :shallow_pathi:shallow_prefix wszystko Opcje domyślne nazwy przestrzeni nazw.

Dostępne opcje zarówno dla zakresu i obszaru nazw odpowiadają postanowieniom meczu .

zakres jest nieco skomplikowany, ale zapewnia więcej opcji do precyzyjnego dostrojenia tego, co chcesz zrobić.

zakres obsługuje trzy opcje: moduł, ścieżka i jako . Jeśli zobaczysz zakres ze wszystkimi opcjami it, będzie dokładnie taki sam jak przestrzeń nazw.

Innymi słowy, trasy generowane przez

namespace :admin do
  resources :posts
end

jest taki sam jak

scope module: 'admin', path: 'admin', as: 'admin' do
  resources :posts
end

Innymi słowy, możemy powiedzieć, że nie ma domyślnych opcji zakresu w porównaniu z przestrzenią nazw. przestrzeń nazw domyślnie dodaje wszystkie te opcje. W ten sposób używając zakresu, możemy bardziej precyzyjnie dostroić trasy zgodnie z wymaganiami.

Jeśli przyjrzysz się dogłębnie domyślnemu zachowaniu zakresu i przestrzeni nazw , zauważysz, że zakres domyślnie obsługuje tylko : opcję ścieżki , gdzie jako przestrzeń nazw obsługuje trzy moduły opcji , ścieżkę i domyślnie.

Aby uzyskać więcej informacji, zapoznaj się z przestrzenią nazw i routingiem dokumentów .