Cela a beaucoup plus de sens maintenant. Je n’ai pas rencontré de problèmes car j’avais l’habitude de redémarrer le serveur, même lorsque je travaillais sur le cœur de Discourse, plutôt que de recharger le code.
Ce que j’ai fait récemment, bien que je ne sois pas encore un expert suprême comme beaucoup d’entre vous dans la création d’applications Rails, c’est de planifier quelles variables de configuration doivent être rechargées sans redémarrer Rails, et de déplacer ce code dans le ApplicationController.
Je suis certain qu’il existe de meilleures façons de faire cela, mais puisque cette implémentation Rails particulière est une application de back-office et que la performance n’est pas un problème :
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
Je serai ravi lorsque je trouverai une meilleure façon de faire cela !
Cependant, déplacer cela hors des initialisateurs de Rails signifie que l’utilisateur peut modifier ce paramètre du site facilement, car il est maintenant dans la base de données en utilisant un scaffold CRUD MVC de base de Rails.
Puisque la mise en cache SQL dans Rails ne fonctionne pas en dehors du scope d’une action, un jour je devrai apprendre comment déplacer cela vers la mise en cache et m’assurer que le cache est vidé lorsque le contrôleur Rails traite l’action (par exemple, sauvegarder une nouvelle valeur dans le contrôleur des paramètres du site, etc.).
Quoi qu’il en soit, cette application Rails cliente (back-office uniquement) n’est pas destinée à une utilisation haute performance, donc ajouter la requête au contrôleur d’application fonctionne bien et m’évite de répéter ce code dans chaque contrôleur du projet où ce paramètre du site est requis.
Salut @fzngagan, je ne suis certainement pas un « Rubyiste » et j’ai beaucoup moins d’expérience avec Rails que la plupart des développeurs de plugins Discourse ; mais cela dit : peut-être pourrez-vous vous en sortir avec quelque chose comme ceci à l’avenir si vous avez besoin de recharger des fichiers dans votre plugin sans redémarrer l’application en production (ou en développement) :
after_initialize do
# modifiez le suivant pour choisir votre contrôleur
# ou utilisez le contrôleur d'application si nécessaire
ApplicationController.class_eval do
before_action :do_my_stuff
def do_my_stuff
load File.open(FAIZAANS_FAV_FILE)
end
end
end
Cela permettra de recharger les fichiers comme prévu.
J’utilise actuellement cela dans un plugin de la manière suivante, et cela fonctionne comme prévu :
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
J’utilise actuellement ce code dans un plugin sur lequel je travaille de temps en temps, qui affiche les noms des conteneurs extraits de ENV["DATA_NAME"] ainsi que l’espace disque extrait d’un code système utilisant df et grep.
Dans nos vues d’administration :
Comme mentionné, je ne suis pas du tout Rubyiste ; mais cette méthode fonctionne pour moi.
J’ai examiné le code du plugin dans instance.rb et, après plusieurs essais et erreurs, j’ai décidé d’utiliser le code class_eval ci-dessus. Ce n’est peut-être pas la méthode préférée, mais cela fonctionne certainement pour moi.
Par exemple, si je recharge la page après avoir supprimé beaucoup de sauvegardes Discourse, l’indicateur d’espace disque change comme prévu.