Bonjour, Finalement, je vais répondre ici même.
@tim : Je pense effectivement qu'on aurait pu décortiquer le modèle en plusieurs autres objets. Il aurait être possible de faire un objet pour la validation, un autre pour la sauvegarde, un autre pour rechercher dans la base de données, un autre pour représenter la donnée uniquement. Je pense que ça fait très JAVA comme manière de faire. Dans notre cas, nous utilisons Rails et donc ActiveRecord. Il faut également savoir profité de ce que nous offre les outils que nous utilisons. Je crois que, par fois, il ne faut pas trop se prendre la tête. Keep It Simple and Stupid. Évidement, si tu en sens le besoin, tu peux le faire. @lucas : Je pense que la classe TokenGenerator est utile. Imagine que tu change de manière de générer un token, veux-tu vraiment changer le code partout ou tu as cette utilisation? En utilisant TokenGenerator, tu auras juste une seule place et c'est fini. Je pense effectivement de connaitre la méthode d’encryptage des tokens est trop d'information pour une classe qui a pour but de créer un utilisateur. Comme je disais dans l'article, il s'agit d'une proposition et pas de la vérité absolue. Si tu juge, dans ton cas, que c'est plus simple de ne pas faire cette classe, ne la fait pas. Au pire, tu le feras quand tu en aura besoin. Tu suivras le principe YAGNI. Merci pour vos commentaires constructif, Guirec. Le 27 juillet 2014 16:00, lucas di cioccio <lucas.dicioc...@gmail.com> a écrit : > Hello Guirec, > > C'est plutôt bien écrit, avec une intro et tout et tout, bravo. > > Pour le contenu, j'ai par contre toussé sur le TokenGenerator. Du coup > j'ai deux trois innocentes questions ouvertes. La classe TokenGenerator > n'illustre-t-elle pas un cas "comiquement dégénéré"? > > J'ai l'impression que tu échanges juste un > > SecureRandom.urlsafe_base64 > par un > > TokenGenerator.new.call > > . > > J'ai du mal à voir où on y gagne vraiment. > > Au final, si tu perds de vue que ta variable est un token_generator, tu es > perdu. Le nom de méthode "call" n'apporte pas beaucoup d'information en > utilisant le "duck-typing" (dans ton exemple, "call" est vraiment > surchargé). Est-ce que tu juges que urlsafe_base64 contient trop de détails? > > On dirait que tu essayes d'avoir deux niveaux à chaque fois: un niveau > élémentaire avec des considérations spécifiques détaillées (atomiques?) et > un niveau de "groupage" qui combine ces responsabilités (moléculaire?). Si > tel est le cas, penses tu que cette approche puisse avoir des inconvénients? > > Cheers, > --Lucas > > > Le 27 juillet 2014 20:56, Tim <itsumo.sibyl...@gmail.com> a écrit : > > Salut >> >> Je pense que tu as écris présidence au lieu de persistance (dans le >> dialogue final) >> >> J ai une question.: Est ce que si on va au bout du concept il ne faudrait >> pas creer un UserValidator ? Est ce que c est au model de se valider lui >> meme ? >> Le 27 juil. 2014 20:36, "Guirec Corbel" <guirec.cor...@gmail.com> a >> écrit : >> >> Bonjour, >>> >>> Je viens de publier un article sur le SRP : http://t.co/UY8LTE7T0w. >>> >>> N'hésitez pas à m'envoyer vos commentaires. >>> >>> -- >>> -- >>> 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+unsubscribe@ >>> googlegroups.com. >>> Pour plus d'options, visitez le site https://groups.google.com/d/optout >>> . >>> >> -- >> -- >> 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 obtenir davantage d'options, consultez la page >> https://groups.google.com/d/optout. >> > > -- > -- > 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 obtenir davantage d'options, consultez la page > https://groups.google.com/d/optout. > -- -- 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/d/optout .
