> par contre, le fait qu'un modele ne porte pas ses validations, je trouve ca > moisi. > un User a forcement un nom de famille, quel que soit le projet dans lequel > tu lutilises. ca fait partie du metier du User et pas de son form.
J'utilise un concept proche de ces FormObject, je les nomme Context. L'idée est également d'encapsuler les validations (ainsi que les #permit de strong_parameters) dans une classe dédiée. Il y a certes des champs qui peuvent être toujours obligatoire, mais le contraire peut aussi être vrai (des champs qui sont *parfois* obligatoires). Typiquement, j'ai le cas dans mon application actuelle où un user peut être quelqu'un qui s'est inscrit sur le site ou un client/lead dont les admins ont enregistré les infos depuis le backend (et qui peut éventuellement avoir un accès sur le site ensuite). Au début, j'étais parti sur du STI, avec BasicUser, OnlineUser et OfflineUser, mais comme d'hab, ça a fini par poser des problèmes (ah au fait, un user peut devenir Customer, maintenant). J'aime bien l'idée d'extraire les validations dans un contexte parce que tout à coup, il n'y a plus besoin de STI, de `validates :if` etc. Si ce n'est pas la même chose d'enregister un Order en étant admin et en étant user, je peux le spécifier sans complications. Et si jamais un champs est vraiment toujours obligatoire, well, je peux toujours ajouter la validation dans le modèle, ce n'est pas une religion. -- -- Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de Google Groups. Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse railsfrance@googlegroups.com Pour résilier votre abonnement envoyez un e-mail à l'adresse railsfrance-unsubscr...@googlegroups.com --- Vous recevez ce message, car vous êtes abonné au groupe Google Groupes Railsfrance. Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse railsfrance+unsubscr...@googlegroups.com. Pour plus d'options, visitez le site https://groups.google.com/groups/opt_out .
