Noms de contrôleurs et d'assistants au singulier ou au pluriel dans Rails


112

Y a-t-il un inconvénient à utiliser des noms singuliers pour les contrôleurs et les assistants? Rien ne semble reposer sur cela. Il semble même que les assistants n'aient pas à faire le même choix entre le singulier et le pluriel que leurs contrôleurs correspondants, du moins selon mon expérimentation limitée. Est-ce vrai?


2
J'ai eu le même dilemme en essayant de décider des noms de contrôleur au singulier ou au pluriel!
Andrew

15
merci :) La culture Rails a un moyen de vous faire sentir stupide si vous remettez en question des choses comme ça.
allyourcode

Réponses:


158

Certainement au pluriel .

Avec un routage reposant et un contrôleur unique

Manette:

dog_controller.rb  

Itinéraires:

map.resources :dogs  # => blows up  
map.resources :dog  # is ok, but...  
dogs_path # => blows up  
dog_path  # => ok  

Utilisation d'un contrôleur pluriel

Manette:

dogs_controller.rb

Itinéraires:

map.resources :dogs  
dogs_path # => ok  
dog_path # => ok  

rails generate controller --help a plusieurs exemples:

Example:
`rails generate controller CreditCards open debit credit close`

CreditCards controller with URLs like /credit_cards/debit.
    Controller: app/controllers/credit_cards_controller.rb
    Test:       test/controllers/credit_cards_controller_test.rb
    Views:      app/views/credit_cards/debit.html.erb [...]
    Helper:     app/helpers/credit_cards_helper.rb

23
D'accord. Il est déroutant que le message d'aide du générateur Rails 3.1 pour les contrôleurs utilise «CreditCard» (au singulier) comme exemple.
bantic

4
Rails help utilise maintenant le pluriel: les rails génèrent le contrôleur CreditCards open débit credit close
notapatch

3
a toujours une seule carte de crédit ici: guides.rubyonrails.org/command_line.html#rails-generate
rcrogers

Comment pouvons-nous écrire des locales pour un contrôleur unique stackoverflow.com/questions/29650094/…
Santosh

La dénomination doit donc être au pluriel et arriver au cas. par exemple:: les rails génèrent le contrôleur Chiens nouvel index créer supprimer détruire éditer "??
BKSpurgeon

27

L'utilisation de noms pluriels pour les contrôleurs n'est qu'une convention.

Les noms au pluriel semblent généralement plus naturels (en particulier pour les contrôleurs qui sont directement liés à un modèle spécifique: Utilisateur -> Utilisateurs, etc.), mais vous pouvez utiliser ce que vous voulez.

En ce qui concerne les helpers, tous les helpers sont disponibles pour tous les contrôleurs par défaut, donc techniquement, la façon dont vous nommez vos helpers n'a pas du tout d'importance. C'est juste une autre convention de conserver les fonctions d'assistance d'un contrôleur dans un assistant avec le même nom que le contrôleur.


10
Ne serait-il pas plus naturel que le contrôleur correspondant à User soit le UserController ?? De plus, si vous comptez sur les routes par défaut, vous obtenez des URL qui ressemblent à / users / edit, ce qui donne l'impression que vous modifiez tous les utilisateurs. Pour moi, ce n'est pas du tout naturel.
allyourcode

5
@allyourcode: eh bien, je suppose que tout est subjectif. pour moi, avoir / users lister tous les utilisateurs est plus naturel que / user.
Can Berk Güder

1
oh, et c'est la manière RESTful.
Can Berk Güder

3
@Can "the RESTful way" sonne comme un chant cultish. Cela ne me surprend pas vraiment, car Rails est globalement assez religieux. J'aime la façon dont Rails est obsédé par REST, mais les routes par défaut ne sont pas reposantes. Même la configuration des routes RESTful n'est pas naturelle. Inclure: conditions => {: method =>: post} dans le deuxième argument pour se connecter n'a aucun sens, car le hachage est censé spécifier comment gérer toute requête qui correspond à la règle actuelle, pas si une requête donnée correspond à la règle actuelle .
allyourcode

2
@allyourcode Selon cela, l'itinéraire par défaut pour l'édition est / users /: id / edit au lieu de / users / edit. Dire "sur tous les utilisateurs, modifier l'utilisateur avec id: id" me semble parfaitement naturel.
DavidG

19

Un modèle est singulier car il fait référence à un seul objet comme User. Un contrôleur est au pluriel car ce sont les contrôles (méthodes) pour la collection d'utilisateurs. La façon dont on nomme les routes dépend de ce développeur individuel. Je n'ai jamais vu un utilisateur se plaindre qu'une URL d'une requête Web soit au singulier ou au pluriel. Le résultat final est de maintenir une convention commune pour les contributeurs actuels et futurs tout en servant des affichages de page de qualité ou les demandes d'API pour les utilisateurs finaux.


12

Vous avez une explication très complète dans les guides Rails: http://edgeguides.rubyonrails.org/routing.html#resource-routing-the-rails-default


4
en fait c'est la bonne réponse b / c si vous la lisez, cela explique que le pluriel est la bonne réponse pour une collection de ressources. Pour une ressource singleton, le singulier est la bonne réponse. Exemples dans la documentation. Et en fait, ceci est bien répondu dans cet autre article: stackoverflow.com/questions/2614858/…
Rob

Les réponses soutenues par des références officielles comme dans cet article aident beaucoup les débutants! Merci
Wasif Hossain

9

Selon la convention Rails, un contrôleur gère un modèle, qu'une ou plusieurs instances de ce modèle puissent exister pendant l'exécution. Cependant, vous pouvez avoir une application Rails dans laquelle (certains des) contrôleurs (et les vues associées) ne sont associés à aucun modèle particulier, mais gèrent plutôt un ensemble plus complexe de fonctionnalités. Dans ce cas, la pluralisation automatique n'a aucun sens.

L'application Rails sur laquelle je travaille actuellement s'inscrit dans cette catégorie, et c'est simplement une irritation pour moi que Rails s'attende à ce que les identificateurs que je définis comme un singulier à un endroit soient ensuite utilisés au pluriel à d'autres endroits. Par exemple, je pourrais vouloir définir quelque chose comme ceci dans config/routes.rb:

  resource :dashboard, :only => [:show]

puis je veux qu'un contrôleur DashboardControlleraffiche des informations récapitulatives sur certains aspects de l'application, collectant des informations à partir de plus d'une table de base de données. Donc ici, Dashboardne fait référence à aucun modèle de l'application, et ce serait juste bizarre d'avoir le nom du contrôleur DashboardsController.

J'ai trouvé une bonne solution à l'irritation de la pluralisation automatique dans cette réponse . En bref, éditez le fichier config/initializers/inflections.rbet ajoutez les mots que vous ne voulez pas être automatiquement mis au pluriel à cette définition:

ActiveSupport::Inflector.inflections do |inflect|
  inflect.uncountable %w( dashboard foo bar baz )
end

3

La convention de dénomination des contrôleurs dans Rails favorise la pluralisation du dernier mot du nom du contrôleur, bien que cela ne soit pas strictement requis (par exempleApplicationController ).

Par exemple, ClientsControllerest préférable à ClientController, SiteAdminsControllerest préférable à SiteAdminController ouSitesAdminsController , et ainsi de suite.

Suivre cette convention vous permettra d'utiliser les générateurs de routes par défaut (ex: ressources, etc.) sans avoir besoin de qualifier chacun :pathou:controller , et gardera votre application cohérente dans l'utilisation des aides URL et le chemin.

Réf: Controller Naming Convention-Rails Doc



2

Si le contrôleur est une ressource, il doit être au pluriel ...

Par exemple

Manette

articles_controller.rb

Modèle

article.rb

Mais vous pouvez utiliser des noms de contrôleurs singuliers lorsque vous n'avez pas de modèles correspondants comme

welcome_controller.rb

1

Utiliser des pluriels sonne mieux, et si vous avez un contrôleur qui gère une ressource singulière, c'est-à-dire un utilisateur, vous pouvez toujours nommer l'url / l'utilisateur.

Avec les helpers, il n'est souvent pas nécessaire d'avoir un assistant pour chaque contrôleur, et souvent il y aura des méthodes d'aide, vous pouvez utiliser plusieurs contrôleurs ascors et plutôt les jeter dans votre assistant d'application, vous pouvez les mettre dans des helpers personnalisés à la place, comme par exemple layout_helper ou tout autre. autre fichier bien nommé.


Mêmes commentaires que pour Can Berk Guder. De plus, j'ai eu du mal à suivre votre dernière phrase / paragraphe car il y avait si peu de ponctuation!
allyourcode

1
Désolée à ce sujet, tout ce que je voulais dire, c'est que ce serait peut-être une meilleure idée de créer des helpers personnalisés plutôt que d'utiliser les valeurs par défaut car les noms par défaut ne capturent pas toujours pleinement où ils vont être utilisés. Si vous disposez d'un certain nombre de méthodes d'assistance qui seront utilisées pour la mise en page, appelez-la layout_helper.
nitecoder
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.