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. On 7 jan, 07:49, Vincent Spehner <[email protected]> wrote: > 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). 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:http://www.ruby-forum.com/topic/201694#878262 > Note:www.blankapplication.orgto get the release 1.0.4. V1.1 coming > this month > -- > Posted viahttp://www.ruby-forum.com/.
-- 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]
