Bonjour Jean-Baptiste, Je vais regarder du côté de spree voir si je peux m'inspirer. J'avais également regardé du côté de RefineryCMS qui fonctionne avec des engines aussi.
Merci pour l'info sur les mountables qui pourraient avoir des différences de comportement lors du passage en prod. Je vais tester. Au départ mon application ne s'adressait qu'à un organisme je l'ai monté pour leurs besoins, mais au fur et à mesure d'autres l'ont vu tourner et me demandent de l'adapter pour leurs structures. Bref je trouvais ça dommage d'installer mon code puis de couper dedans en fonction des besoins et de réécrire par dessus. Je veux rendre mon application plus "générique". Un socle commun que j'installe puis j'active ou non les engines en fonction des besoins. Si une nouveauté est demandée, je fais un nouvel engine qui sera utilisable pour les autres applications déjà en service et les futures installations. Merci pour la réponse. Le mardi 26 novembre 2013 08:13:54 UTC-5, Jean-Baptiste BARTH a écrit : > > Hello, > > Spree ( > https://github.com/spree/spree<https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fspree%2Fspree&sa=D&sntz=1&usg=AFQjCNG9m6IRvL-3usLFo9wPLdCKpj1dyw> > ) > est à mon avis un bon exemple d'appli qui mobilise plusieurs engines et les > fait interagir entre eux. Ca peut être une source d'inspiration, le but est > de fournir un truc extensible et de petites perles (genre la gem "deface") > fournissent des moyens élégants de se plugger sur le code du coeur. > > Convention pour nommer, je sais pas honnêtement, à toi de voir. > > Full vs mountable : du mountable sera par définition plus isolé et > beaucoup plus limité en fonctionnalités. L'avantage théorique est > l'isolation de namespaces. Attention, je sais pas si c'est fixé en 4 ni si > ça a été remonté, mais l'isolation de namespaces fonctionne pas pareil en > environnement "development" et en "production", j'ai déjà vu des trucs > gauffrer en prod et faut manipuler ça avec doigté... A tester un minimum > manuellement avant de passer en prod trop confiant. > > Avant de se lancer là dedans c'est la même chose pour moi que le > découplage de grosses applis dans des services web différents : il faut le > faire si ça pose vraiment un problème et qu'on est sûr d'y gagner plus > qu'on y perd en difficultés de maintenance, design, hétérogénéité, etc. Il > y a déjà eu des threads sur cette liste là dessus, parfois le monolithique, > ça peut être bien, juste parce que c'est plus simple et que tu te poseras > moins de questions (on n'est pas tous google ou twitter..). > > Mes 2 centimes, > > > Le 26 novembre 2013 13:38, Antoine <[email protected] <javascript:>> a > écrit : > >> Bonjour à tous. >> >> >> Je suis en pleine mise à jour d'une de mes app vers rails4. Je voulais >> profiter de cette mise à niveau pour séparer mon code en plusieurs engines. >> Je me suis dit que j'avais tout intérêt à poser mes questions avant plutôt >> que mes erreurs après. >> >> L'application de base est un outil de gestion des membres pour les >> organisations à but non lucratif. J'installe cette application dans les >> différentes structures et je modifie mon code pour l'adapter aux besoins >> des situations. Pour gagner du temps je pensais déplacer une partie des >> fonctionnalités dans des engines. L'objectif est d'avoir une application de >> départ épurée et où l'on puisse facilement ajouter des options. >> >> J'ai joué un peu avec des engines dans une application de test et j'ai >> pas mal épluché les docs et autres blog sur le sujet. Voici les questions >> que je me pose encore et que je voulais élucider avant de réécrire le code: >> >> 1 - Convention pour nommer les engines: >> >> Au départ j'ai nommé l'engine par le nom de sa fonctionnalité. Par >> exemple si je voulais ajouter la gestion des activités pour les membres je >> nommais l'engine: Activity. Mais lorsqu'on veut générer un modèle du même >> nom on se rend compte que l'opération ne va pas être possible. >> >> Je pensais nommer de la façon suivante: >> applicationdebase_nomdelafonctionnnalité (ex: member_activity) >> >> 2 - full vs mountable >> >> J'ai lu pas mal sur cette question. Beaucoup de personnes semblent >> utiliser et documentent le côté mountable ( les guides, le livre: rails >> recipes etc... ). J'ai essayé les deux options. Full permet vraiment une >> implantation simple et rapide de sa fonction ( pas de routage à ajouter, >> pas d'isolation de nom qu'il ne faut pas oublier etc). Mais je suis >> conscient des risques de collision avec les noms de mes classes/tables ... >> Ma question est: si je suis seul à mettre les mains dans le code est-ce >> malgré tout un risque ou un mauvaise habitude à ne pas prendre? Le code >> n'aura pas vocation à être utilisé ailleurs que dans cette application. >> >> 3 - "if engine exists?" >> >> Dans l'application de base je pensais mettre tout le code dont les >> engines auront besoin. Par exemple dans la barre latérale je voudrai >> afficher les dernières activités mais seulement si l'engine est installé. >> Si l'engine est présent le code dans ma vue sera utilisé sinon non. >> >> Pendant mes tests j'ai utilisé: >> >> if defined? Activity >> @activities = Activity.allend >> >> et dans mes vues: >> >> <% if defined? Activity %> >> <h3><%= @activities.first.title %></h3><% end %> >> >> Tout fonctionne mais est-ce une bonne pratique? A-t-on des alternatives? >> J'ai pensé à une zone d'option dans l'application où l'on pourrait >> "activer" l'engine une fois installée et remplacer le "defined?" par une >> vérification de la valeur de l'option. >> >> Quels sont vos idées/usages/coutumes avec les engines. Quels sont vos >> conseils avant de se lancer dans le découpage de mon application? >> >> Merci! >> >> ps: j'ai posé cette question sur stackoverflow mais je souhaitais avoir >> le plus d'avis >> possible<http://www.google.com/url?q=http%3A%2F%2Fstackoverflow.com%2Fquestions%2F20203392%2Frails-best-pratice-engines&sa=D&sntz=1&usg=AFQjCNGXFKQnBYW5R9x6Prxb6lSNdy0MLQ> >> . >> >> -- >> -- >> 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 >> [email protected] <javascript:> >> Pour résilier votre abonnement envoyez un e-mail à l'adresse >> [email protected] <javascript:> >> --- >> 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 >> [email protected]<javascript:> >> . >> Pour plus d'options, visitez le site >> https://groups.google.com/groups/opt_out . >> > > -- -- 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 [email protected] Pour résilier votre abonnement envoyez un e-mail à l'adresse [email protected] --- 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 [email protected]. Pour plus d'options, visitez le site https://groups.google.com/groups/opt_out .
