なるほど、納得です。Discourse コアを作業中であっても、コードをリロードする代わりにサーバーを再起動していたので、私は問題に直面したことがありませんでした。
最近、Rails アプリ構築において皆さんほど超エキスパートではない私が行ったのは、Rails を再起動せずに再読み込みすべき設定変数を計画し、そのコードを ApplicationController へ移動させることです。
もっと良い方法があるのは確かですが、この特定の Rails 実装はバックオフィス用アプリであり、パフォーマンスは問題ではないためです:
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
より良い方法を見つけられたときは嬉しいです!
ただし、これを Rails のイニシャライザから外すことで、ユーザーはこれをデータベース上の基本的な Rails MVC CRUD スケルトンとして簡単にサイト設定を変更できるようになります。
Rails の SQL キャッシュはアクションの範囲外では機能しないため、いつかこれをキャッシュに移行し、Rails コントローラがアクションを処理する際(例えば、サイト設定コントローラで新しい値を保存するなど)にキャッシュがクリアされるようにする方法を学ぶ必要があります。
とにかく、このクライアント向け Rails アプリ(バックオフィス専用)は高性能用途ではないため、クエリを ApplicationController に追加するだけで十分機能し、プロジェクト内の各コントローラでこのサイト設定が必要な場合にコードを繰り返す必要がなくなります。
@fzngagan さん、こんにちは。私は「Rubyist」ではなく、Discourse プラグイン開発者の多くに比べて Rails の経験も浅いのですが、それでも言わせていただくと:もし本番環境(または開発環境)でアプリケーションを再起動せずにプラグイン内のファイルをリロードする必要がある場合は、将来的には以下のような方法で対応できるかもしれません。
after_initialize do
# 以下を好みのコントローラーに変更してください
# または必要であれば Application Controller を使用してください
ApplicationController.class_eval do
before_action :do_my_stuff
def do_my_stuff
load File.open(FAIZAANS_FAV_FILE)
end
end
end
これにより、期待通りにファイルがリロードされます。
現在、私はプラグインで以下のようにこの方法を使用しており、期待通りに動作しています。
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
私は現在、このコードを自分が時々取り組んでいるプラグインで使用しています。このプラグインは、ENV["DATA_NAME"] から解析されたコンテナ名と、df や grep を使用したシステムコードから解析されたディスク容量を表示するものです。
管理画面のビューでは:
前述の通り、私は Rubyist ではありませんが、この方法でうまくいっています。
instance.rb 内のプラグインコードを検討し、いくつかの試行錯誤の後、上記の class_eval コードを採用することにしました。これがベストプラクティスとは限りませんが、私にとっては確かに機能しています。
例えば、Discourse のバックアップを大量に削除した後にページをリロードすると、ディスク容量インジケーターが期待通りに更新されます。
