2013-06-27 15 views
10
  1. Quando è possibile nidificare percorsi nel blocco devise_for? Si prega di dare uno o due esempi per mostrare il caso d'uso. (Percorsi # 1)Rails3 + Devise: Quando nidificare la risorsa in devise_for & risorse nidificate

  2. Se :foo_object è associata a :users così :user has_one :foo_object, non ho bisogno di nido :foo_object sotto :users? (Percorsi n. 2) :users è il modello di dispositivo :users.

Percorsi # 1:

devise_for :users 
resource :foo_object 

Percorsi # 2:

devise_for :users 
resources :users do  
    resource :foo_object 
end 

risposta

23

Il seguente esempio:

devise_for :users, :path => 'accounts' 

resources :users do 
    resources :orders 
end 

Quanto sopra significa che il percorso di autenticazione sarebbe "/accounts/sign_in" , "/accounts_sign_up" ecc. Alcuni potrebbero non sapere che è importante riconoscere che lo in realtà non è la mappa per il UsersController e il modello. Non è nemmeno una risorsa, anche se molti credono che sia. Che è il motivo per cui non possiamo trattarlo come il seguente:

devise_for :users do 
    resources: somereosouce 
end 

Tutto devise_for fa è mappare i seguenti itinerari:

# 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"} 

Così nel dire che si poteva fare la seguente, ma avrebbe alcuni conflitti :

devise_for :users 

resource :users do 
    resource :foo_object 
end 

Un po 'sulle risorse nidificate, se avete qualcosa di simile al seguente:

class Users < ActiveRecord::Base 
    has_many :foo_object 
end 

class FooObject < ActiveRecord::Base 
    belongs_to :users 
end 

Allora la vostra risorsa nidificato sarebbe

resource :users do 
    resource :foo_object 
    end 

Speriamo che questo cancella le cose. Inoltre potresti voler leggere Nested Resource with Devise - Rails3

+2

Grazie per aver chiarito la domanda 'devise_for'. Migliore spiegazione che ho letto! – HM1

+0

Per Q # 2, so che è quello che farei per nidificare la risorsa ... Suppongo che la domanda sia più necessaria o devo nidificare la risorsa per i modelli associati per questo caso? Perché in questo caso, posso usare 'current_user' nel controller e creare/aggiornare il modello': foo_object'. Mi chiedo se ci siano conseguenze per farlo in questo modo. – HM1

+1

@ HM1 non è esattamente necessario no, ma se vuoi definire qualche logica la tua applicazione allora sì. È un modo più pulito di raggruppare le risorse. Comunque nel tuo caso sai che un 'utente' è associato a' foo_object'. In questo modo, quando esegui un'azione su un utente, eseguirai anche un'azione "foo_object". Quindi il tuo URL potrebbe sembrare qualcosa del genere '/ users/3/foo_object/4' Un altro motivo per cui sarebbe necessario avere percorsi nidificati è perché RESTful è uno dei principi importanti in Rails. – David

Problemi correlati