Je souhaite créer un plugin qui nécessite ses propres tables. Il serait donc judicieux de disposer de générateurs de migrations et de modèles, car copier manuellement ces fichiers depuis le répertoire principal de l’application entraîne des erreurs et n’est pas très pratique. J’ai donc commencé à développer mes propres générateurs, en commençant par le générateur de migrations :
Je pourrais maintenant passer aux modèles et aux contrôleurs avec la même approche. Cependant, en commençant à lire cette documentation Getting Started with Engines — Ruby on Rails Guides, il me semble que tout cela pourrait constituer une duplication d’efforts. Pourquoi le générateur de plugins Discourse s’écarte-t-il autant du générateur de plugins Rails ?
Le générateur de plugins Rails crée un fichier bin/rails spécifique au plugin, qui active les générateurs de migrations et de modèles propres à ce plugin. Il serait agréable d’avoir une fonctionnalité similaire. J’ai essayé de créer quelque chose de semblable, mais je n’ai pas réussi à le faire fonctionner, alors j’ai emprunté une autre voie en créant directement ces générateurs très spécifiques. Si je comprenais mieux les différences entre l’approche Rails et l’approche Discourse pour créer des plugins, je pourrais peut-être opter pour cette autre voie, ce qui pourrait me faire gagner du temps. Peut-être que quelqu’un pourrait développer ce point. Pourquoi les plugins Discourse et Rails sont-ils si différents et pourquoi ne s’appuient-ils pas l’un sur l’autre ?
Les plugins Rails diffèrent des plugins Discourse pour de nombreuses raisons. Les plugins Discourse doivent avoir une structure de dossiers spécifique, ils peuvent étendre ou remplacer le code Ember du cœur de Discourse, etc. Je pense que la partie Rails d’un plugin Discourse serait plus proche d’un plugin Rails générique, mais ce ne sont pas exactement la même chose.
De plus, il ne faut créer de nouvelles tables que si elles sont vraiment nécessaires. Discourse possède déjà environ 150 tables, et il n’est pas rare que votre travail soit achevé en utilisant une seule ou quelques-unes d’entre elles.
Cependant, pour l’avenir, j’aimerais personnellement voir cela se produire. Cela signifierait que des personnes créent des plugins énormes et plus passionnants, et qu’elles deviennent plus créatives dans ce qui peut être réalisé avec Discourse.
J’en ai besoin. Même les fonctionnalités de base nécessitent des tables. Je trouve vraiment frustrant qu’il n’existe pas de méthode clairement documentée pour le faire. Par exemple, le plugin de sondage utilise ses propres tables, mais je ne parviens pas à trouver le générateur permettant de les créer. discourse/plugins/poll at main · discourse/discourse · GitHub
Un autre avantage de la documentation est qu’elle permettrait d’établir des conventions pour l’espace de nommage des tables et des migrations. (J’ai vu ici même sur les forums des solutions vraiment bidouillées recommandées pour ajouter des migrations à un plugin).
Super ! Alors, quelle voie choisir ? S’approcher du générateur de plugins Rails avec un propre bin/rails dans le dossier du plugin, ou créer ses propres versions pour tous les générateurs (migrations, modèles, contrôleurs) ?
Vous devez lire les sujets du tutoriel de développement de plugin ici. Pour la plupart des plugins, vous pouvez utiliser des tables existantes (comme les champs personnalisés des publications). Il arrive parfois que vous ayez besoin de tables supplémentaires, mais il serait probablement préférable de commencer par quelque chose de moins complexe.
J’ai lu le guide pour les débutants sur les plugins et ceci. Y a-t-il autre chose ? J’ai également examiné le code de certains plugins. Je sais juste qu’il faut des tables. Et il existe d’autres plugins qui utilisent leurs propres tables. Pourquoi cette obsession à ne pas créer de nouvelles tables ? Y a-t-il un coût élevé lié à la création de nouvelles tables ? Surtout si elles sont namespacees avec le nom du plugin au début, je ne vois vraiment pas l’inconvénient.
Voici ces liens. Je recommande vivement de les consulter en pratique avant de faire tout commentaire relatif au développement. Cela ne signifie pas que vous n’aurez jamais besoin de tables personnalisées, mais ces ressources sont indispensables de toute façon.
Ceci n’est qu’un simple stockage clé-valeur. Je ne peux pas y stocker de relations entre les tables. J’aime SQL. Et j’ai besoin de l’utiliser pour le plugin que je souhaite créer.
Je comprends que ce problème s’applique aux personnes qui souhaitent créer des plugins que des « non-techniciens » puissent installer et désinstaller. Je ne fais pas partie de ces personnes. Je serais donc heureux si nous pouvions revenir au sujet.
Si l’intention est de créer quelque chose que vous utiliserez uniquement vous-même, à mon avis, il serait probablement préférable d’écrire une extension de navigateur ou une application de bureau plutôt qu’un plugin. Y a-t-il une raison pour laquelle cela doit obligatoirement être un plugin ?