5

J'ai mis en héritage de table unique pour une classe de personnesRails brisés Routes après la mise en œuvre de table unique héritage

class Person < ActiveRecord::Base 

end 


class Teacher < Person 

end 

class Student < Person 

end 

class Outsider < Person 

end 

Et la personne créer semble travailler la création de professeur, étudiant ou personne selon la ce qui est choisi sous la forme .select et l'attribut type est ajouté.

Cependant, il me semble avoir brisé les routes

<% = link_to 'Edit', edit_person_path (@deal)%> | <% = link_to 'Retour', chemin_personnel%

Ils semblent pointer vers teacher_path, student_path et outsider_path au lieu de person_path.

Quels changements doivent être faits dans les routes?

Répondre

2

d'abord générer des contrôleurs pour vos modèles ...

rails generate controller Persons 
rails generate controller Teachers 
rails generate controller Students 
rails generate controller Outsiders 

puis dans routes.rb (rails 3)

resources :persons 
resources :teachers 
resources :students 
resources :outsiders 

vous donne le repos des itinéraires

par exemple

persons GET /persons(.:format) {:action=>"index", :controller=>"persons"} 
new_person GET /person/new(.:format) {:action=>"new", :controller=>"persons"} 
edit_person GET /persons/:id/edit(.:format) {:action=>"edit", :controller=>"persons"} 
person GET /persons/:id(.:format) {:action=>"show", :controller=>"persons"} 
persons POST /spersons(.:format) {:action=>"create", :controller=>"persons"}  
person PUT /persons/:id(.:format) {:action=>"update", :controller=>"persons"}  
person DELETE /persons/:id(.:format) {:action=>"destroy", :controller=>"persons"} 

même pour l'enseignant, étudiant et extérieur

routes râteau à cocher ou des routes râteau | enseignants grep

+2

je ne veux pas que différents contrôleurs pour chacun – Arc

+0

donc vous perdrez REST ajouter à routes.rb match 'enseignants /' => "personnes index #",: as =>: professeurs match de « enseignant /: id (:. Format) »=> "personnes # show",: as =>: les enseignants et ainsi de suite ... – codevoice

+1

cela fonctionne, mais pas du tout DRY - vous finirez par répéter tout le code du contrôleur, et le code de vue encore et encore pour chaque sous-classe – Tilo

1

D'après mon expérience, il est préférable d'utiliser un contrôleur unique pour tous les modèles STI. Si vous maintenez vos contrôleurs au sec, vous ne devriez pas avoir besoin d'une logique de contrôleur unique pour chaque classe enfant. Garde tout ça dans les modèles.

resources :people 

Vos itinéraires seront nommés comme:

people_path 
new_person 
edit_person 
person 
etc... 

Ensuite, vous pouvez utiliser le même contrôleur/vues pour gérer ces modèles. Si vous décidez ultérieurement d'ajouter de nouveaux modèles Person STI, vous n'aurez pas besoin de mettre à jour de manière significative votre code.

+2

Cela ne semble pas fonctionner. Pour <% = link_to 'Modifier', edit_person_path (@deal)%> il essaie de trouver edit_teacher_path (@user) et échoue – Arc

+0

se débattait avec moi-même tout à l'heure .. Je veux traiter mes sous-modèles significativement différemment dans les vues et préférerait ne pas avoir un tas de logique conditionnelle dans le contrôleur ou la vue .. pensées? –