2013-06-27 8 views
10
  1. Wann sollte ich Routen im devise_for Block verschachteln? Bitte geben Sie ein oder zwei Beispiele an, um den Anwendungsfall zu zeigen. (Routes # 1)Rails3 + Devise: Wann verschachteln Ressourcen in devise_for & nested resources

  2. Wenn :foo_object ist im Zusammenhang mit :users so :user has_one :foo_object, muss ich Nest :foo_object unter :users? (Routen # 2) :users ist das Gerät :users Modell.

Routen # 1:

devise_for :users 
resource :foo_object 

Routes # 2:

devise_for :users 
resources :users do  
    resource :foo_object 
end 

Antwort

23

das folgende Beispiel:

devise_for :users, :path => 'accounts' 

resources :users do 
    resources :orders 
end 

Das obige bedeutet, dass der Authentifizierungs-Pfad "/accounts/sign_in" wäre , "/accounts_sign_up" etc .. Einige können nicht wissen, dass es wichtig ist zu bestätigen, dass die devise_for :users nicht tatsächlich Karte auf die UsersController und das Modell. Es ist nicht einmal eine Ressource Route, auch wenn viele glauben, es sieht so aus. Welches ist, warum wir es wie die folgende nicht behandeln kann:

devise_for :users do 
    resources: somereosouce 
end 

Alle devise_for tut, ist über die folgenden Routen Karte:

# Session routes for Authenticatable (default) 
    new_user_session GET /users/sign_in     {:controller=>"devise/sessions", :action=>"new"} 
     user_session POST /users/sign_in     {:controller=>"devise/sessions", :action=>"create"} 
destroy_user_session GET /users/sign_out     {:controller=>"devise/sessions", :action=>"destroy"} 

# Password routes for Recoverable, if User model has :recoverable configured 
    new_user_password GET /users/password/new(.:format)  {:controller=>"devise/passwords", :action=>"new"} 
    edit_user_password GET /users/password/edit(.:format) {:controller=>"devise/passwords", :action=>"edit"} 
     user_password PUT /users/password(.:format)   {:controller=>"devise/passwords", :action=>"update"} 
         POST /users/password(.:format)   {:controller=>"devise/passwords", :action=>"create"} 

# Confirmation routes for Confirmable, if User model has :confirmable configured 
new_user_confirmation GET /users/confirmation/new(.:format) {:controller=>"devise/confirmations", :action=>"new"} 
    user_confirmation GET /users/confirmation(.:format)  {:controller=>"devise/confirmations", :action=>"show"} 
         POST /users/confirmation(.:format)  {:controller=>"devise/confirmations", :action=>"create"} 

So zu sagen, dass Sie das folgende würde tun könnte, aber einige Konflikte haben :

devise_for :users 

resource :users do 
    resource :foo_object 
end 

Ein wenig auf verschachtelte Ressourcen, wenn Sie so etwas wie die folgenden haben:

class Users < ActiveRecord::Base 
    has_many :foo_object 
end 

class FooObject < ActiveRecord::Base 
    belongs_to :users 
end 

Dann verschachtelte Ressource wäre

resource :users do 
    resource :foo_object 
    end 

Hoffentlich Dinge aufklärt. Vielleicht möchten Sie auch ein Lesen von Nested Resource with Devise - Rails3

+2

Vielen Dank für die Klärung der 'devise_for' Frage. Beste Erklärung, die ich gelesen habe! – HM1

+0

Für Q # 2 weiß ich, dass ich das tun würde, um die Ressource zu verschachteln ... Ich denke, die Frage ist mehr von ist es notwendig, oder muss ich die Ressource für assoziierte Modelle für diesen Fall verschachteln? Denn in diesem Fall kann ich 'current_user' im Controller verwenden und das': foo_object' Modell erstellen/aktualisieren. Ich frage mich, ob es Konsequenzen dafür gibt. – HM1

+1

@ HM1 es ist nicht unbedingt notwendig nein, aber wenn Sie eine Logik Ihrer Anwendung dann ja definieren möchten. Es ist eine sauberere Art, Ihre Ressourcen zu gruppieren. In Ihrem Fall wissen Sie jedoch, dass ein 'Benutzer' mit' foo_object' verbunden ist. Wenn Sie also eine Aktion für einen "Benutzer" ausführen, würden Sie auch eine Aktion "foo_object" ausführen. So würde Ihre URL möglicherweise so etwas wie dieses aussehen '/ users/3/foo_object/4' Ein anderer Grund, warum es verschachtelte Routen benötigt, ist, weil es RESTful eines der wichtigen Prinzipien in Rails ist. – David

Verwandte Themen