Das ergibt jetzt viel mehr Sinn. Ich bin nicht auf Probleme gestoßen, weil ich, selbst wenn ich am Kern von Discourse arbeitete, einen Server-Neustart durchführte, anstatt den Code neu zu laden.
1 „Gefällt mir“
Was ich kürzlich gemacht habe – ich bin noch nicht so ein Super-Experte wie viele von euch beim Erstellen von Rails-Apps – ist, zu planen, welche Konfigurationsvariablen neu geladen werden sollen, ohne Rails neu zu starten, und diesen Code in den ApplicationController zu verschieben.
Ich bin mir sicher, dass es bessere Wege gibt, dies zu tun, aber da diese spezielle Rails-Implementierung eine Back-Office-Anwendung ist und die Leistung kein Problem darstellt:
class ApplicationController < ActionController::Base
before_action :set_site_settings
private
def set_site_settings
@use_custom_date_format = Sitesetting.where(name: "custom_date_format").pluck(:value).last
end
end
Ich werde mich freuen, wenn ich einen besseren Weg finde, dies zu tun!
Das Verschieben aus den Rails-Initialisierern bedeutet jedoch, dass der Benutzer diese Seiteneinstellung leicht ändern kann, da sie sich jetzt in der Datenbank befindet und über ein einfaches Rails-MVC-CRUD-Scaffold verwaltet wird.
Da das SQL-Caching in Rails außerhalb des Geltungsbereichs einer Aktion nicht funktioniert, muss ich eines Tages lernen, wie man dies in den Cache verschiebt und sicherstellt, dass der Cache geleert wird, wenn der Rails-Controller die Aktion verarbeitet (z. B. einen neuen Wert im Site-Settings-Controller speichern usw.).
Wie auch immer, diese clientseitige Rails-Anwendung (nur Back-Office) ist nicht für den Hochleistungsgebrauch gedacht, daher funktioniert das Hinzufügen der Abfrage zum ApplicationController gut und erspart mir, diesen Code in jedem Controller des Projekts zu wiederholen, in dem diese Seiteneinstellung erforderlich ist.
2 „Gefällt mir“
Hallo @fzngagan, ich bin sicherlich kein „Rubyist“ und habe deutlich weniger Erfahrung mit Rails als die meisten Discourse-Plugin-Entwickler; aber dennoch: Vielleicht könnten Sie in Zukunft mit etwas Ähnlichem auskommen, wenn Sie Dateien in Ihrem Plugin neu laden müssen, ohne die Anwendung in der Produktion (oder Entwicklung) neu zu starten:
after_initialize do
# Ändern Sie dies zu Ihrem gewünschten Controller
# oder verwenden Sie den Application Controller, falls erforderlich
ApplicationController.class_eval do
before_action :do_my_stuff
def do_my_stuff
load File.open(FAIZAANS_FAV_FILE)
end
end
end
Dies lädt die Dateien wie erwartet neu.
Ich verwende dies derzeit in einem Plugin wie folgt, und es funktioniert wie erwartet:
after_initialize do
Admin::AdminController.class_eval do
before_action :do_neo_plugin_info
def do_neo_plugin_info
load File.open(PLUGIN_LOGIC)
end
end
end
Ich verwende diesen Code derzeit in einem Plugin, an dem ich von Zeit zu Zeit arbeite. Es zeigt die Namen der Container an, die aus ENV["DATA_NAME"] geparst werden, sowie den Festplattenspeicher, der mithilfe von Systemcode mit df und grep ermittelt wird.
In unseren Admin-Ansichten:
Wie erwähnt, bin ich keineswegs ein Rubyist; aber diese Methode funktioniert für mich.
Ich habe mir den Plugin-Code in instance.rb angesehen und nach einigen verschiedenen Versuchen und Irrtümern beschlossen, den oben genannten class_eval-Code zu verwenden. Es mag nicht der bevorzugte Weg sein, Dinge zu tun, aber es funktioniert definitiv für mich.
Wenn ich beispielsweise die Seite neu lade, nachdem ich viele Discourse-Backups gelöscht habe, ändert sich der Festplattenspeicher-Indikator wie erwartet.