Ich möchte ein Plugin erstellen, das eigene Tabellen benötigt. Daher ist es eine gute Idee, Generatoren für Migrationen und Modelle bereitzustellen, da das manuelle Kopieren aus dem Haupt-App-Verzeichnis zu Fehlern führt und einfach nicht sehr praktisch ist. Also habe ich begonnen, eigene Generatoren zu entwickeln. Ich habe mit dem Migrationsgenerator gestartet:
Ich könnte jetzt fortfahren und das Gleiche für Modelle und Controller tun. Aber gerade habe ich angefangen, dies zu lesen: Getting Started with Engines — Ruby on Rails Guides, und nun scheint es mir, als wäre all dies eine Doppelarbeit. Warum weicht der Discourse-Plugin-Generator so stark vom Rails-Plugin-Generator ab?
Der Rails-Plugin-Generator erstellt ein plugin-spezifisches bin/rails, das die plugin-spezifischen Generatoren für Migrationen und Modelle aktiviert. Es wäre schön, etwas Ähnliches zu haben. Ich habe versucht, etwas Vergleichbares zu erstellen, konnte es aber nicht zum Laufen bringen, also bin ich den anderen Weg gegangen und habe einfach diese speziellen „Einzelstücke"-Generatoren erstellt. Wenn ich die Unterschiede zwischen der Rails- und der Discourse-Methode zur Erstellung von Plugins besser verstehen würde, könnte ich vielleicht diesen anderen Weg gehen, was Zeit sparen könnte. Vielleicht kann jemand dies näher erläutern. Warum sind Discourse- und Rails-Plugins etwas Unterschiedliches, und warum bauen sie nicht aufeinander auf?
Rails-Plugins unterscheiden sich aus vielen Gründen von Discourse-Plugins. Discourse-Plugins müssen eine bestimmte Ordnerstruktur aufweisen und können den Ember-Code des Kerns von Discourse erweitern oder überschreiben. Die Rails-Seite eines Discourse-Plugins wäre zwar einem generischen Rails-Plugin ähnlicher, aber es sind nicht dasselbe.
Außerdem sollte man nur dann neue Tabellen erstellen, wenn sie wirklich notwendig sind. Discourse verfügt bereits über rund 150 Tabellen, und es kommt nicht allzu häufig vor, dass Ihre Aufgabe nicht mit einer oder wenigen davon erledigt werden kann.
Dennoch würde ich persönlich hoffen und begrüßen, dass dies in Zukunft geschieht. Das würde bedeuten, dass Menschen großartige und aufregendere Plugins entwickeln und kreativer damit umgehen, was mit Discourse möglich ist.
Ich brauche sie. Selbst grundlegende Funktionen erfordern Tabellen. Ich finde es wirklich ärgerlich, dass es keine klar dokumentierte Möglichkeit gibt, dies zu tun. Beispielsweise verwendet das Poll-Plugin eigene Tabellen, aber ich kann den Generator für deren Erstellung nicht finden. discourse/plugins/poll at main · discourse/discourse · GitHub
Ein weiterer Vorteil der Dokumentation wäre, dass es Konventionen für die Namensgebung von Tabellen und Migrationen geben würde. (Ich habe hier im Forum einige sehr haklige Lösungen empfohlen gesehen, wie man Migrationen zu einem Plugin hinzufügt.)
Toll! Also, welcher Weg ist der richtige? Sich dem Rails-Plugin-Generator mit eigenem bin/rails im Plugin-Ordner annähern oder eigene Versionen für alle Generatoren (Migrationen/Modelle/Controller) erstellen?
Du musst die Anleitungen zur Plugin-Entwicklung hier lesen. Für die meisten Plugins kannst du vorhandene Tabellen verwenden (z. B. benutzerdefinierte Felder für Beiträge). Es gibt Fälle, in denen du zusätzliche Tabellen benötigst, aber es wäre ratsam, zunächst mit etwas weniger Komplexem zu beginnen.
Ich habe den Einsteiger-Guide für Plugins und diesen gelesen. Gibt es noch etwas anderes? Ich habe mir auch den Code einiger Plugins angesehen. Ich weiß nur, dass ich Tabellen benötige. Und es gibt weitere Plugins, die eigene Tabellen verwenden. Warum gibt es diese Obsession, keine neuen Tabellen zu erstellen? Ist mit der Erstellung neuer Tabellen ein großer Aufwand verbunden? Besonders wenn sie mit dem Plugin-Namen am Anfang namespace sind, sehe ich wirklich keinen Nachteil.
Genau diese hier. Ich empfehle dringend, diese praktisch durchzugehen, bevor du dich zu irgendetwas im Zusammenhang mit der Entwicklung äußerst. Nicht, dass du nie benutzerdefinierte Tabellen brauchst, aber diese sind auf jeden Fall ein Muss.
Dieses Ding ist im Grunde nur ein einfacher Key-Value-Speicher. Dort kann ich keine Beziehungen zwischen Tabellen speichern. Ich mag SQL. Und ich muss es für das Plugin verwenden, das ich erstellen möchte.
Ich verstehe, dass dieses Problem für Leute gilt, die Plugins erstellen wollen, die von „nicht-technischen Personen
Wenn die Absicht darin besteht, etwas zu erstellen, das nur du selbst nutzen wirst, wäre meiner Meinung nach die Entwicklung einer Browsererweiterung oder einer Desktop-App statt eines Plugins wahrscheinlich besser. Gibt es einen Grund, warum dies zwingend ein Plugin sein muss?