Bah les vues c'est toujours la misere pour ca, nottament parce qu'il est beaucoup plus difficile de ne pas penser en "global". Ca depend aussi de la complexite qu'il y a derriere.
J'aurais envie de te repondre "fais des strategies en JS que tu instancies au besoin, qui encapsulent leur "comportement visuel" ..." mais si ton metier est trop simple, c'est une perte de temps. Render un partial qui porte le nom de la strategie est peut-etre beaucoup plus simple et tout a fait approprie selon moi (on render bien des partials dont le nom est determine a partir des noms de classes AR). De plus, la solution citee ne fonctionne vraiment qu'en Singe Page Application, sinon c'est plus l'horreur qu'autre chose je pense.. Dur dur de repondre comme ca. Mes excuses les plus belges (le plat pays, tout ca) Le 11 avril 2014 17:17, Olivier Gosse-Gardet <olivier.gosse.gar...@gmail.com > a écrit : > Merci beaucoup Florian pour ce retour ! > Effectivement, l'approche par Strategy/fichier de config est plus > intelligente à moyen terme. > La voie que je voulais prendre était un peu trop Quick and Dirty. > > En allant plus loin, comment appliquerais-tu cela aux vues > ? Concrètement, dans mon cas, les vues sont à 70 % identique en terme de > contenu pour chaque des clients, mais les 30% restants peuvent être très > différent. J'aimerais autant que possible éviter des conditions dans les > vues elle même et éviter les engines qui disperse un peu trop la logique > applicative à mon gout. > Mon idée est ici de faire une sorte de render qui détermine la version du > partial a inclure en fonction des stratégies en cours. Ça a pour moi > l'avantage de centraliser une partie de la logique applicative dans un > endroit identifié. Cette idée me tente bien, mais elle ne me semble pas > respecter l'art et la manière Rails. > > > > > Le 11 avril 2014 10:29, Florian Dutey <fdu...@gmail.com> a écrit : > > Que penses tu de ceci? >> >> * tout ce qui est valeurs brutes non configurables par le client lui meme >> => un fichier de config yml propre a chaque client >> * chaque comportement => une classe dans un namespace "Strategy" >> >> s'il y a des strategies a differents niveaux, tu fais plusieurs >> namespaces, genre: Strategy::User, Strategy::Account >> >> * la liste des strategies qu'utilise un client => dans le fichier yaml >> >> Tu peux tester unitairement chacune de tes strategies >> Tu peux eclater les fichiers de config en en faisant un par strategie si >> yen a trop >> Ton appli est une collection de strategies et un client est juste une >> combinaison de celles ci (tu peux tester unitairement les combinaison aussi >> en creant un fichier de spec qui porte le nom du client pour mieux >> identifier la combinaison) >> >> Et pour les "valeurs brutes", tu testes une seul fois la classe qui lit >> le fichier yaml, tu peux mettre des validations dessus (histoire qu'une >> appli ne puisse pas demarrer si tu as rajoute une valeur cruciale et que tu >> as oublie de mettre a jour tes yamls) >> >> Tu peux facilement developper une app a cote qui gere ta liste de >> clients, leurs options et genere des fichiers yaml sur les serveurs (ou >> capistrano va crawl une url pour recuperer le fichier yaml quand tu >> deploies, bref, t'as le choix dans la date). >> >> Si t'as plus de 3 clients, et que le projet evolue beaucoup, maintenir >> des classes qui sont juste des matrices de methodes (souvent vides), ca >> risque de devenir vite l'enfer. >> Je prefere nettement les fichiers de config quand il s'agit de .... >> config :p >> >> >> Le 11 avril 2014 03:00, thierry henrio <thierry.hen...@gmail.com> a >> écrit : >> >>> >>> >>> >>> 2014-04-10 17:30 GMT+02:00 Olivier Gosse-Gardet < >>> olivier.gosse.gar...@gmail.com>: >>> >>> Bonjour, >>>> >>>> J'ai une application destinée à plusieurs clients. Chacun de ces >>>> clients utilisera une instance différente de l'application. Chaque client a >>>> des propriétés et fonctionnalités différentes. >>>> Mon idée est d'utiliser des classes différentes héritant d'une classe >>>> maitre. >>>> >>> >>> composition > inheritance >>> >>> >>>> J'ai donc fait quelque chose comme >>>> class ClientMain >>>> end >>>> >>>> class Client1 < ClientMain >>>> end >>>> >>>> class Client2 < ClientMain >>>> end >>>> >>>> et défini dans un initializer de rails une sorte d'alias de classe en >>>> faisant par exemple : >>>> Client = Client2 >>>> >>>> Mon code et mes vues manipulent uniquement Client. >>>> Tout à l'air de marcher correctement. Ca m'intrigue. >>>> >>> >>> Comment est-ce que tu fais pour tester ton code si Client n'existe que >>> dans un initializer ? >>> C'est forcément Client1 ou Client2 >>> Ou alors tu remplace Client dans tes tests ? >>> ?? >>> >>> Qu'en pensez-vous ? >>>> >>> >>> Ce que j'en pense est que si ça marche pour toi, et bien why not >>> >>> Les autres options sont >>> * engines <http://guides.rubyonrails.org/engines.html> >>> * lib >>> + assemblage ( initializers, whatever ) >>> >>> , Thierry >>> >>> -- >>> -- >>> 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 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 .
