Ça me semble être un bon début. Maintenant, il ne me reste plus qu’à apprendre à faire de vraies choses cool avec.
Mon premier plan est d’écrire du code pour interroger la base de données afin de récupérer une valeur dont j’ai besoin dans la table post_custom_fields et de l’utiliser sur la page des sujets pour un petit élément demandé par notre équipe de modérateurs chevronnés.
Demain, je vais la récupérer depuis Git et commencer à chercher du code d’exemple pour la base de données dans d’autres plugins pour démarrer et voir jusqu’où je peux aller.
Chaque petit coup de main compte, et avoir un générateur comme celui-ci pour les débutants dans la création de plugins Discourse comme moi est très apprécié. Vous pouvez le voir là-bas, tout en bas, qui implore d’être développé :
Au fil des ans, j’ai écrit d’innombrables plugins pour vBulletin, alors je suis vraiment enthousiaste à l’idée de créer quelques plugins simples pour Discourse, croyez-moi.
Toujours en train d’apprendre les plugins Discourse, je suis revenu aujourd’hui sur ce générateur de plugins ; et j’ai essayé ceci dans un environnement de développement sur macOS, où l’application fonctionne parfaitement et où j’ai beaucoup étudié Ruby et Rails et créé de petits plugins pour apprendre :
# cd /var/Tim/Discourse/plugins
# rails g plugin DiscourseRacoon
# bundle exec 'rails s'
Tout semble se passer correctement, et le plugin s’installe sans problème :
Ai-je tort de penser que les routes du plugin et le contrôleur devraient fonctionner immédiatement (OOTB) après la génération du plugin de base, dans ce cas DiscourseRacoon ?
Je me suis rendu sur diverses références en ligne, qui indiquaient qu’il fallait vérifier que la route existait ; j’ai donc vérifié routes.rb et des routes y sont bien définies ; j’ai également vérifié discourse_racoon_controller.rb et le contrôleur contient bien une méthode index (action).
Désolé, je suis toujours en difficulté avec le développement de plugins plus avancés et Discourse. Qu’est-ce que je fais mal ? Avez-vous des suggestions sur quelle serait ma prochaine étape pour déboguer ce problème ?
Je suppose que c’est une convention Rails que je dois apprendre ? Où toutes les routes définies avec des tirets du bas sont accessibles avec des tirets ?
DiscourseRacoon::Engine.routes.draw do
get "/" => "discourse_racoon#index", constraints: DiscourseRacoonConstraint.new
get "/actions" => "actions#index", constraints: DiscourseRacoonConstraint.new
get "/actions/:id" => "actions#show", constraints: DiscourseRacoonConstraint.new
end
J’ai généré un plugin « Hello World » avec ce générateur, ajouté plusieurs instructions Ruby pour écrire dans un fichier et observé le cycle de vie de Rails. J’ai constaté que les contrôleurs Rails ne fonctionnaient pas comme prévu (ils ne produisaient aucun journal, ce qui indiquait qu’ils étaient ignorés).
Après avoir effectué un débogage, j’ai réussi à faire fonctionner le plugin comme attendu en déplaçant les contrôleurs Rails d’un niveau de répertoire vers le haut.
En outre, j’ai ajouté un contrôleur et un modèle JavaScript/Ember pour la page d’index principale, intégré du HTML et du CSS dans tous les modèles, et ajouté du code JavaScript pour lire les cookies et mettre en surbrillance les modèles.
Par exemple, après quelques modifications apportées au plugin généré par le générateur de plugins Rails :
Pour tous les détails et captures d’écran, veuillez consulter :
Pour conclure, je tiens à remercier @j.jaffeux pour ce générateur de plugins Rails. J’ai pris beaucoup de plaisir à déboguer les contrôleurs Rails et à les modifier afin d’ajouter davantage de code pour inspecter à la fois le cycle de vie de Rails et les modèles/contrôleurs JavaScript.
J’espère que mes modifications aideront toute personne, comme moi, qui apprend encore les bases du développement de plugins Discourse dans son temps libre et souhaite utiliser le générateur de plugins Rails.
Voir aussi :
Actuellement, je m’amuse énormément à déboguer et à corriger des plugins défectueux dans le cadre de mon apprentissage du développement de plugins pour Rails et Discourse
Merci d’avoir résolu cela, @neounix ! Peut-être que cela me donnera l’élan nécessaire pour faire avancer mon projet.
Salut @j.jaffeux, est-ce que déplacer ces fichiers constitue la solution recommandée, ou devraient-ils être inclus via quelque chose comme :
load File.expand_path('some-path-here', __dir__)
Je pense avoir essayé de les inclure, mais j’ai alors reçu une erreur concernant un élément manquant… (je suppose donc que j’ai fait la mauvaise manipulation et que cela ne vaut pas la peine de documenter exactement ce qui s’est passé).
EDIT : Il semble que le contrôleur soit bien chargé/exécuté lors de l’accès à /plugin-path.
J’ai d’abord essayé de charger les contrôleurs Ruby avec des instructions load dans plugin.rb, mais ils ne se sont pas enregistrés comme prévu.
Lorsque j’ai testé les contrôleurs Ruby, j’ai utilisé des instructions Ruby pour écrire dans le système de fichiers et lancé une commande tail -f sur ce fichier de journal pour vérifier le déclenchement des contrôleurs.
Pour m’amuser, j’ai terminé ma journée d’hier en écrivant du code qui lit toutes les variables d’environnement du processus dans un cookie via un contrôleur Rails, puis les envoie à l’application via le contrôleur Ember.
Dans la partie 4 du guide des plugins de @eviltrout, il recommande de développer le plugin en dehors du code source de Discourse et de créer un lien symbolique dans le répertoire plugins.
Est-il logique d’ajouter une option -d ~/chemin/vers/plugin_src pour générer le plugin dans un autre répertoire, et éventuellement aussi configurer le lien symbolique ?
