Discourse Plugins und Rails 6 config/initializers Frage

Entwickler
1

Hallo, ihr Discourse-Plugin-Experten,

nur eine kurze Frage zu Discourse-Plugins und Rails-Initialisierern.

Wenn ein Discourse-Plugin ein Verzeichnis namens „config

2 „Gefällt mir“
2

Ich möchte auch wissen, wie sich ein Discourse-Plugin von einem gewöhnlichen Rails-Engine unterscheidet. Ich habe mir zwar den Quellcode angesehen, aber nicht viel verstanden.

3

Nach einem flüchtigen Blick auf Ruby on Rails Guides: Configuring Rails Applications bin ich der Meinung, dass plugin.rb im Grunde dasselbe ist. Die meisten Plugins von nennenswerter Größe nutzen es als Einstiegspunkt für die Logik, nicht als die Logik selbst.

4

Ja, ich habe diesen Rails-Guide in letzter Zeit häufig gelesen. Grundsätzlich bin ich mit der Funktionsweise der Rails 6-Konfiguration „zufrieden

5

[quote=“neounix, Beitrag: 4, Thema: 168373”]
Ich frage mich nur, ob wir dieselbe Struktur in einem Discourse-Plugin (für Initializer) verwenden können, ob Rails die Initializer in den Unterverzeichnissen wie in Rails 6 liest; oder ob wir das Initializer-Verzeichnis des Plugins als Konfigurations-„Asset

3 „Gefällt mir“
6

Das sehe ich auch so.

Du lädst alle zusätzlichen benötigten Ruby-Dateien innerhalb von plugin.rb.

Hier ist ein Beispiel aus dem Follow-Plugin:

1 „Gefällt mir“
7

Das entspricht auch meinem Eindruck, nachdem ich eine Reihe von Discourse-Plugins auf GitHub gelesen habe.

Es scheint, dass Discourse nur plugin.rb liest und wir alle anderen Ruby-Dateien, die wir benötigen – etwa Initializer – in plugin.rb laden müssen.

Ich hatte jedoch gehofft, dass ich mich irre und es eine „tiefere

1 „Gefällt mir“
8

[quote=“neounix, Beitrag: 7, Thema: 168373”]
Ich hatte jedoch gehofft, dass ich mich irre und es eine „tiefere

9

Ja, das ist kein Problem, die Initialisierer in plugin.rb aufzurufen und zu laden.

Der Grund für meine Frage war, dass ich derzeit eine ziemlich große Rails 6-Anwendung für ein Unternehmen schreibe, bei der ich ihre veralteten Backoffice-Skripte (über mehrere Jahrzehnte) in eine Rails-Anwendung umwandle. Um Initialisierer hinzuzufügen, habe ich einfach ein Unterverzeichnis unter config/initializers (in Rails), und alle meine Initialisierer-Dateien werden so schön eingebunden, ohne dass ich Code schreiben muss, um diese Dateien in Rails einzuschließen.

Danke für alle eure Antworten. Das wird sehr geschätzt!

1 „Gefällt mir“
10

Ja, ich würde es toll finden, wenn die Rails-Vorteile auf Discourse-Plugins übertragen würden. Einer meiner persönlichen Favoriten wäre die Möglichkeit, Ruby-Dateien live neu zu laden, ohne den Server neu zu starten.

1 „Gefällt mir“
11

Dafür ist reloadable_patch gedacht. Wenn du Änderungen an Ruby-Klassen in reloadable_patch einschließt, sollten sie live neu geladen werden!

1 „Gefällt mir“
12

Kann ich die gesamte plugin.rb-Datei dafür im Dev-Modus einpacken? Ernster gefragt: Wie weit können wir damit gehen?

Außerdem: Das Hinzufügen neuer Dateien oder das Ändern von YAML-Dateien erfordert einen Server-Neustart, oder?

2 „Gefällt mir“
13

Du solltest nicht für alles ein reloadable_patch anwenden müssen. Viele der in instance.rb definierten Methoden, die die Plugin-Entwicklung erleichtern, verwenden intern reloadable_patch, wie zum Beispiel add_to_serializer.

Idealerweise ist unsere Plugin-API so gut gestaltet, dass du nicht eine wahnsinnige Menge an reloadable_patch-Aufrufen vornehmen musst.

Ja, das stimmt. Ich frage mich, ob man etwas gegen die Änderungen an YAML-Dateien unternehmen kann; das stört mich persönlich.

3 „Gefällt mir“
14

Das ist absolut richtig. Ich wusste nicht, dass reloadable_patch dazu gedacht ist, das Live-Reloading zu unterstützen. Mir fallen viele Anwendungsfälle ein, bei denen Discourse es bereits verwendet, aber auch darüber hinaus. Zum Beispiel:

reloadable_patch do
 require 'x/y/z'
end

or Monkey-Patches.

1 „Gefällt mir“
15

Ich denke, das Entfernen oder Hinzufügen einer solchen Funktion wäre immer noch problematisch, da reloadable_patch innerhalb der Funktion aufgerufen wird.

In jedem Fall hilft das sehr.

1 „Gefällt mir“
16

Ich habe mich mit dem Live-Reload von YAML-Änderungen beschäftigt, und das funktioniert tatsächlich. Plugins können dieses Live-Reload unterbrechen, wenn sie reloadable_patch nicht ordnungsgemäß verwenden. Sobald jedoch alle Ihre Plugins sicher neu geladen werden können, werden auch Ihre YAML-Änderungen neu geladen.

4 „Gefällt mir“
17

Es wäre jedoch super hilfreich, wenn du die genauen Schritte zur Verwendung von reloadable_patch beschreiben könntest.

Hier ist mein Versuch, der leider nicht funktioniert hat (mir fehlt sicher etwas):

after_initialize do
    add_to_serializer(:topic_view, :check, false) do
        puts 'nocheck'
    end
end

Sobald der Server startet und ich nocheck in check ändere, wird nach dem Neuladen der Topic-Route immer noch nocheck ausgegeben.

after_initialize do
    reloadable_patch do |plugin|
        puts 'nocheck'
    end
end

Auch beim Neuladen einer beliebigen Seite nach dem Ändern des Strings unter puts habe ich immer noch keinen Erfolg.

20

Ich vermute, ich habe Sie in den obigen Beiträgen irreführende Informationen gegeben. reloadable_patch ist hilfreich für die Discourse-Entwicklung, aber @david hat die Verwendung sehr gut erklärt:

Alles, was sich im after_initialize-Block von plugin.rb befindet, wird nur während des Starts der Anwendung geladen, nicht jedoch bei nachfolgenden Neuladungen.

Angenommen, Sie möchten dem User-Serializer etwas hinzufügen. Das normale Verhalten wäre dann wie folgt:

Beim Start:

  • Discourse lädt user_serializer.rb
  • Discourse lädt plugin.rb, das eine Überschreibung für user_serializer enthält

Beim Neuladen:

  • Discourse lädt user_serializer.rb neu
  • (Der Patch aus plugin.rb wird nicht neu geladen, die Plugin-Überschreibung geht verloren)

Mit unserem reloadable_patch-System:

Beim Start:

  • Discourse lädt user_serializer.rb
  • Discourse lädt plugin.rb und registriert den reloadable_patch für den User-Serializer
  • Die reloadable Patches werden ausgeführt

Beim Neuladen:

  • Discourse lädt user_serializer.rb neu
  • Die reloadable Patches werden ausgeführt
  • (Hurra, die Plugin-Überschreibung funktioniert weiterhin)
6 „Gefällt mir“
21

Hier wird eine grundlegende Eigenschaft von Rails beschrieben, die für Discourse nicht direkt relevant ist.

In Rails werden alle Initialisierer nur beim Start von Rails geladen. Daher wird Code, der von einem Initialisierer wie „after_initializer

6 „Gefällt mir“
22

Ja genau! Das ist korrekt, und dein Verständnis von Rails-Initialisierern ist ebenfalls richtig.

Ich bin ebenfalls ein großer Rails-Fan :slight_smile:

7 „Gefällt mir“