Das sieht für mich nach einem guten Start aus. Jetzt muss ich nur noch lernen, wirklich coole Dinge damit zu machen.
Mein erster Plan ist es, Code zu schreiben, der die Datenbank abfragt, um einen Wert aus der Tabelle post_custom_fields zu erhalten, den ich auf der Themen-Seite für eine kleine Anforderung unseres erfahrenen Moderator-Teams verwenden kann.
Morgen werde ich es aus Git pullen und nach Beispiel-Code für Datenbanken aus anderen Plugins suchen, um einen Einstieg zu finden und zu sehen, wie weit ich komme.
Jeder kleine Schritt zählt, und ein Generator wie dieser für Anfänger wie mich, die Discourse-Plugins entwickeln, wird sehr geschätzt. Ihr könnt ihn dort unten sehen, der darauf wartet, entwickelt zu werden:
Im Laufe der Jahre habe ich unzählige Plugins für vBulletin geschrieben, daher bin ich wirklich aufgeregt, einfache Plugins für Discourse zu entwickeln, glaubt mir.
Ich versuche immer noch, mehr über Discourse-Plugins zu lernen. Heute bin ich wieder zu diesem Plugin-Generator zurückgekehrt und habe dies in einer Entwicklungsumgebung unter macOS ausprobiert, wo die App einwandfrei läuft. Ich habe mich intensiv mit Ruby und Rails auseinandergesetzt und kleine Plugins erstellt, um dazuzulernen:
# cd /var/Tim/Discourse/plugins
# rails g plugin DiscourseRacoon
# bundle exec 'rails s'
Alles scheint gut zu laufen, und das Plugin wird problemlos installiert:
Habe ich falsch verstanden, dass die Plugin-Routen und der Controller nach der Generierung des Basis-Plugins (in diesem Fall DiscourseRacoon) sofort (OOTB) funktionieren sollten?
Ich habe verschiedene Online-Ressourcen konsultiert, die darauf hinweisen, dass man prüfen sollte, ob die Route existiert. Also habe ich routes.rb überprüft – dort sind Routen definiert – und auch discourse_racoon_controller.rb, wo der Controller eine index-Methode (Aktion) besitzt.
Entschuldigung, ich kämpfe immer noch mit der interessanteren Plugin-Entwicklung und Discourse. Was mache ich falsch? Hast du einen Vorschlag, wie ich als Nächstes vorgehen sollte, um das Problem zu debuggen?
Ich nehme an, das ist eine Rails-Konvention, die ich lernen muss? Dass alle mit Unterstrichen definierten Routen mit Bindestrichen aufgerufen werden?
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
Ich habe mit diesem Generator ein Hello-World-Plugin erstellt, eine Reihe von Ruby-Anweisungen zum Schreiben in eine Datei hinzugefügt und den Rails-Lebenszyklus beobachtet. Dabei stellte ich fest, dass die Rails-Controller nicht wie erwartet funktionierten – sie protokollierten nichts, was darauf hindeutete, dass sie ignoriert wurden.
Nach dem Debuggen habe ich dies erreicht, indem ich die Rails-Controller ein Verzeichnis nach oben verschoben habe.
Zusätzlich habe ich einen JavaScript/Ember-Controller und eine Vorlage für die Hauptindexseite hinzugefügt, HTML und CSS zu allen Vorlagen hinzugefügt und JavaScript-Code geschrieben, um Cookies auszulesen und die Vorlagen hervorzuheben.
Zum Beispiel, nach einigen Änderungen am Plugin, das vom Rails-Plugin-Generator erstellt wurde:
Abschließend möchte ich mich bei @j.jaffeux für diesen Rails-Plugin-Generator bedanken. Es hat mir großen Spaß gemacht, die Rails-Controller zu debuggen, und ich habe es genossen, sie so zu modifizieren, dass mehr Code bereitgestellt wird, um sowohl den Rails-Lebenszyklus als auch die JS-Vorlagen/Controller zu untersuchen.
Ich hoffe, meine Änderungen helfen anderen, die wie ich noch die Grundlagen von Discourse in der Plugin-Entwicklung in ihrer Freizeit lernen und den Rails-Plugin-Generator nutzen möchten.
Siehe auch:
Derzeit macht es mir großen Spaß, kaputte Plugins im Rahmen des Lernprozesses für die Rails- und Discourse-Plugin-Entwicklung zu debuggen und zu reparieren
Danke, dass du das herausgefunden hast, @neounix! Vielleicht ist das genau der Schub, den ich brauche, um mein Projekt voranzubringen.
Hey @j.jaffeux, ist das Verschieben dieser Dateien die empfohlene Lösung, oder sollten sie stattdessen mit etwas wie
load File.expand_path('some-path-here', __dir__)
eingeschlossen werden?
Ich glaube, ich habe versucht, sie einzubinden, aber dann trat ein Fehler wegen eines fehlenden … irgendetwas auf (also gehe ich davon aus, dass ich etwas falsch gemacht habe und es nicht lohnt, genau zu dokumentieren, was genau).
EDIT: Es sieht so aus, als würde der Controller tatsächlich geladen/ausgeführt, wenn man /plugin-path aufruft.
Ich habe ursprünglich versucht, die Ruby-Controller mit load-Anweisungen in plugin.rb zu laden, aber sie wurden nicht wie erwartet geloggt.
Beim Testen der Ruby-Controller habe ich Ruby-Anweisungen verwendet, um ins Dateisystem zu loggen, und eine tail -f auf dieser Logdatei ausgeführt, um zu prüfen, wie die Controller feuern.
Zur Abwechslung habe ich gestern am Ende des Tages noch Code geschrieben, der alle Prozess-ENV-Variablen in ein Cookie mit einem Rails-Controller liest und sie mit dem Ember-Controller in die App schreibt.
Der URL-Teil steht auf der linken Seite, der Ruby-Code-Bezug auf der rechten Seite von =>. Das _ im Vergleich zu - wird in der Engine-mount-Zeile definiert.
In Teil 4 von @eviltrouts Plugin-Anleitung empfiehlt er, das Plugin außerhalb des Discourse-Quellcodes zu entwickeln und in dem Verzeichnis plugins eine symbolische Verknüpfung einzurichten.
Wäre es sinnvoll, eine Option -d ~/path/to/plugin_src hinzuzufügen, um das Plugin in einem anderen Verzeichnis zu generieren und möglicherweise auch die symbolische Verknüpfung einzurichten?
