Je me demandais s'il y a la meilleure pratique sur où stocker les paramètres globaux dans une application Rails. Ce que je veux dire par là est i.e: j'ai quelques globaux définis qui peuvent changer, mais pas probablement et il semble inapproprié de les stocker dans DB, car ils sont tellement utilisés. Par exemple, j'ai System_Email & System_EMail_Signature & System_Storage_root.
À l'heure actuelle, je les garde dans Environnement.rb, mais je ne suis pas sûr que ce soit le bon palce à les stocker.
merci
La réponse acceptée est toujours aussi appropriée, mais je l'ai depuis passé à utiliser https://github.com/markbates / configatron , il existe d'autres options mais j'aime le plus configatron le plus.
6 Réponses :
Environnement.rb est l'endroit. Vous pouvez l'ajouter à un module et l'ajouter au répertoire lib. Ensuite, vous pourriez l'appeler comme module :: my_global_variable. Les deux ont des points forts et des points faibles. Dans l'environnement.rb est ok mais parfois cela semble désordonné. Si toutes ces variables globales sont liées, vous pouvez regrouper puis dans un module.
rails 3 introduit l'objet d'application. Même avec des rails 2, vous voudrez peut-être stocker vos globaux de la même manière.
Intéressant, j'ai commencé à regarder des rails 3 récemment - spécifiquement des itinéraires, mais je n'ai pas lu beaucoup d'autre. J'y jetterais un œil. Merci pour le pointeur Marc
Étant donné que de telles valeurs changent souvent en fonction de l'environnement que vous utilisez, je stocke les globaux globaux dans config / environnements / développement.rb | production.rb | test.rb , avec des valeurs appropriées pour chaque environnement.
Que diriez-vous de constantes qui devraient être les mêmes de Dev / Prod / Test? Plutôt que de les stocker dans les trois, existe-t-il un fichier qui s'applique aux trois environnements?
La réponse à mon propre commentaire semble être /config/environment.rb. Quelqu'un s'il vous plaît corriger-moi si je me trompe.
Merci d'avoir posté cette confirmation @ben, je cherchais juste à la recherche exacte de la même chose.
Cela semble être une bonne réponse que celle marquée comme «réponse». Pourquoi la déclaration de cas pour les environnements si des rails le fait déjà pour vous?
Notez également que si vous utilisez Environnement.rb, vous aurez probablement besoin de définir vos constantes avant votre nom :: Application.Imitialize!
Je stocke ces informations de configuration dans un fichier YML. Reportez-vous à cette CASSE SCREE-CAST pour plus de détails.
Alternativement, vous pouvez utiliser un gemme appelé app_config .
Une de mes techniques préférées consiste à mettre un fichier contenant les constantes dans le répertoire config / initialiseurs / code> (tous les fichiers de ce répertoire sont chargés automatiquement) mais avec une section pour chaque environnement de rails. E.G.
EMAIL_CONSTANTS = YAML.load_file("#{RAILS_ROOT}/config/email_constants.yml")[RAILS_ENV]
Merci Sean. J'aime que tu abordnes le plus - sauf que je ne pense pas avoir besoin de séparer en e-mail_constants.yml - je vais tout simplement garder tout dans contacnts.yml
Normalement quand je fais quelque chose comme ça, j'ai deux façons de faire cela
1 - Si mes variables globales sont communes à tous les 3 environnements (développement, test, production), je le stockerai dans
fichier config / environnements.rb fichier
mais permet de dire que mes valeurs changent sur l'environnement
ex: mon environnement de développement System_storage_root est '/ Development_root /' and Test Environment System_Storage_root est '/ test_root /'
Alors je les stockerai à l'intérieur
config / environnements /
selon l'exemple ci-dessus
config / environnements / développement.rb aura System_storage_root = '/ Development_root /'
config / environnements / test.rb aura System_storage_root = '/ test_root /'
config / environnements / production.rb aura System_storage_root = '/ production_root /'
J'espère que cela aide,
acclamations, Sameera