vzmind
1
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: Modularity, engines and loading - Engines - Ruby-Forum
Note: www.blankapplication.org to get the release 1.0.4. V1.1 coming
this month
vzmind
2
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)
vzmind
3
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:
- mise en plugin du cms
- c’est le premier plugin chargé (cf fichier config/environment.rb)
- Les extensions partagé peuvent surcharger le plugin
- 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.
vzmind
4
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. 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