# Modularité, engines et override **URL:** \ **Category:** FR\ **Created:** [January 7, 2010, 7:49am UTC](https://www.ruby-forum.com/t/modularita-engines-et-override/181199 "2010-01-07T07:49:51Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![vzmind](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/v/4af34b/32.png) [@vzmind](https://www.ruby-forum.com/u/vzmind)\ **Post date:** [January 7, 2010, 7:49am UTC](https://www.ruby-forum.com/t/modularita-engines-et-override/181199/1 "2010-01-07T07:49:51Z")
Bonjour à tous, nous travaillons chez thinkDRY sur un CMS 2.0 OpenSource, la BlankApplication. Après un an de travail et d’implémentation pour différents clients, nous avons achevé le développement du coeur de l’application. Pour la rendre totalement modulaire, faciliter les développements de la communautés et suivre l’exemple des meilleurs projets OpenSource Rails du moment (Radiant, Spree), nous souhaitons mettre en place un mécanisme d’extensions ([http://spreecommerce.com/documentation/extensions.html](http://spreecommerce.com/documentation/extensions.html)). Les engines sont a priori la meilleure façon de réaliser cela. Cependant, lors de la création de la premiere extension nous avons été confronté à un principe de chargement qui veut que ce soit les controllers/models/vues de l’application principale qui “surdéfinissent” ceux présent dans les engines. Or comme notre coeur est dans l’application principale… ajouter des engines ne permet pas d’étendre les fonctions natives. Je pensais pouvoir inverser cette règle avec des Dependencies:load\_path mais après 2jours de recherche sur le web, je n’ai toujours pas solution. J’ai bien essayé de faire une tache rake d’install déplacant les fichiers du coeur mais bonjour les conflits dans git et la maintenabilité à terme !! Avez-vous une idée, une piste? – VS Original post: [Modularity, engines and loading - Engines - Ruby-Forum](http://www.ruby-forum.com/topic/201694#878262) Note: [www.blankapplication.org](http://www.blankapplication.org) to get the release 1.0.4. V1.1 coming this month ---
**Author:** ![vzmind](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/v/4af34b/32.png) [@vzmind](https://www.ruby-forum.com/u/vzmind)\ **Post date:** [January 7, 2010, 11:13am UTC](https://www.ruby-forum.com/t/modularita-engines-et-override/181199/2 "2010-01-07T11:13:45Z")
Le 07/01/10 07:49, Vincent Spehner a écrit : > sont a priori la meilleure façon de réaliser cela. > solution. J’ai bien essayé de faire une tache rake d’install déplacant > les fichiers du coeur mais bonjour les conflits dans git et la > maintenabilité à terme !! > > Avez-vous une idée, une piste? Personnellement, je ne suis pas convaincu que les Engine soit réélement le meilleur solution. Typiquement Radians n’utilise pas engine et c’est selon moi la meilleur solution. Le développement d’un système de plugin/extension custom à votre cas peux rapidement se montrer plus performant, surtout au niveau sandboxing que vous gérer ainsi beaucoup mieux. Typiquement dans Typo, les helpers défini dans Typo sont loader automatiquement par l’application de manière custom. Ca marche super bien (merci Neuro) ---
**Author:** ![vzmind](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/v/4af34b/32.png) [@vzmind](https://www.ruby-forum.com/u/vzmind)\ **Post date:** [January 7, 2010, 7:44pm UTC](https://www.ruby-forum.com/t/modularita-engines-et-override/181199/3 "2010-01-07T19:44:52Z")
C’est une mauvaise idée d’avoir le cms au sein de l’application Rails car dans ce cas l’utilisateur ne peut faire aucune custo et que ca complique beaucoup les mises à jour du cms. Comme ca dans ton appli rails tu as les tests spécifiques à ce qui est construit avec le cms, les assets spécifique à l’utilisation de ton cms, et les modèles spécifique à l’intégration. C’est également une mauvaise idée de patcher le fonctionnement de rails au niveau de sa politique de chargement parce que c’est un peu poilu avec les histoires de cache class, cache view, reloading auto … A mon avis une meilleur archi serait: 1. mise en plugin du cms 2. c’est le premier plugin chargé (cf fichier config/environment.rb) 3. Les extensions partagé peuvent surcharger le plugin 4. Le code de l’application rails peut surcharger le tout et ne contient QUE du code client Pour mettre à jour le cms il suffit de faire un update du submodule plugin correspondant au cms. Pour completer le tout il faut gérer une copie d’asset du plugin cms vers le public globale, mais tu as déjà le problème avec tes extensions qui voudrait avoir leur propre assets. Sinon tu as le choix de ne pas utiliser les plugins rails qui ne doivent pas t’apporter grand chose si ce n’est le support des taches rake et script/plugin install et ce que tu appelles les engines (qui ne dépendent pas du tout des plugins et pourrait aussi être dans un autre rep) mais de faire ton propre système de plugin, c’est vraiment pas compliqué en ruby. ---
**Author:** ![vzmind](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/v/4af34b/32.png) [@vzmind](https://www.ruby-forum.com/u/vzmind)\ **Post date:** [January 8, 2010, 9:20am UTC](https://www.ruby-forum.com/t/modularita-engines-et-override/181199/4 "2010-01-08T09:20:16Z")
Merci beaucoup pour ces premiers éléments. Je vais installer ces trois applications et étudier d’un peu plus pres le fonctionnement de leurs Engines/Extensions. Est-ce que l’un d’entre vous à déjà eu a travailler avec ces systemes? Comme notre CMS contient déjà une bonne dizaine de plugins, je pense que pour l’embarquer il nous le mettre dans un engine. Je vais demander au dev de faire ca. Première Etape. Avez-vous quelques Best practices concernant ce sujet? Regardez simplement [demo.blankapplication.org](http://demo.blankapplication.org). C’est l’ancienne version mais ca vous donnera une idée. (Login: guest/secret). En fait nous avons déjà 2 engines gérant les 2 métiers principaux de notre outils. Acts\_as\_item et acts\_as\_container. Le premier est pour gérer génériquement toutes formes de contenu et les actions classiques associées (video, article, pages, RSS etc… en CRUD, rating, comment, searchable etc…). Le deuxième est pour organiser ces dits items (workspace, folder, website, shop). Nous partions dans une “morcellisation” systématiques des fonctionnalités dans plusieurs acts\_as… Mais si je comprends bien il faudrait mieux n’en faire qu’un pour ensuite mettre la partie client dans l’app ou des extensions. Le problème malgré tout est que notre système se basant aussi sur un nombre conséquent de gems, comment pouvons-nous les embarquer dans l’engine? Avec une tache rake d’install? Mais bon je devie, de toute facon on passera aussi en SaaS dès que possible. Je vous tiens informé de l’avancement. ## Regards, Vzmind Skype Id: vzmind mail: vincent (arobase) thinkdry (point) com