Dans Django, les paramètres sont stockés dans un fichier, des paramètres.py. Ce fichier fait partie du code et entre dans le référentiel. Ce ne sont que les développeurs qui traitent de ce fichier. L'administrateur traite des modèles, les données de la base de données. Il s'agit des données que le personnel de non-développement modifie et les visiteurs de site voient rendu dans des modèles.
La chose est, notre site, et beaucoup d'autres, disposent de nombreuses options de réglages qui devraient être modifiées par le personnel de non-développeur. Nous parlons de constantes autonomes à l'échelle de site qui n'ont vraiment aucune place dans la base de données. Les mettre dans la base de données entraîneront de nombreuses requêtes inutiles. La mise en cache pourrait atténuer cela, mais cela semble complexe inutilement de gérer ce qui peut être fait avec une seule ligne dans le fichier Paramètres.py.
J'ai remarqué Cette application Dbsettings , mais elle est ancienne et homondiée. J'ai également remarqué que l'application Django E-Commerce, Satchmo, comprend une fourchette spécifique de cas d'utilisation de cette application Dbsettings. Nous pourrions construire quelque chose de similaire sur notre site, une application qui stocke certains paramètres sous forme de paires de clé / valeur dans une seule table de base de données, mais cela semble vraiment comme la mauvaise approche. Pourquoi mettre quelque chose dans la DB qui n'appartient pas là simplement pour le rendre plus facilement modifiable par des non-développeurs?
Nous avons une liste des paramètres de site sur notre site Django que nous voulons être modifiables par des administrateurs non développeurs. Quelle est la meilleure façon d'aller à ce sujet?
5 Réponses :
Que diriez-vous de mettre un sitesettings.py (ou autre) quelque part que vos administrateurs peuvent accéder, alors dans les paramètres.py do
from sitesettings import *
Cette solution ne fonctionne pas non plus car seules les technologies peuvent modifier des fichiers sur le serveur et / ou redémarrer l'Apache.
quelque chose comme Dbsttings (comme vous l'avez mentionné) semble être la voie à suivre. Du raisons de l'existence pour ce projet: < / p>
Tous les paramètres n'appartiennent pas à
paramètres.py , comme il en a quelques Limitations particulières:
Les paramètres sont à l'échelle du projet. Cela nécessite non seulement des applications pour encombrer
paramètres.py , mais augmente également les chances de nommer Conflits.Les paramètres sont constants dans une instance de Django. Ils ne peuvent pas être changé sans redémarrer l'application.
Paramètres nécessitent un programmeur pour être modifié. C'est vrai même Si le réglage n'a aucun impact fonctionnel sur quoi que ce soit d'autre.
Si Dbsettings ne fonctionne pas pour vous, puis mettez votre propre, ou la fourchette. Il ne semble pas que ce soit trop ardu.
Je suis en fait un grand fan de Dbsettings, et gardez le sens de publier ma fourchette qui la corrige pour travailler avec Django 1.1 (pas en réalité un gros changement) . On dirait que quelqu'un a Mise à jour déjà .
Cependant, vous avez probablement raison que cela est surkill pour ce dont vous avez besoin. Une chose que j'ai faite auparavant est d'ajouter une ligne à la fin des paramètres.py qui importe et analyse un fichier YAML. YAML est une langue de balisage simple, qui est la plus basique, il s'agit de la clé Si vous mettez cela quelque part que les éditeurs peuvent accéder à Il est alors à la fin des paramètres.py vous venez de faire: Vous aurez besoin du Python Yaml Bibliothèque pour analyser le fichier YML. L'inconvénient de cette approche est que vous devez redémarrer Apache pour l'obtenir pour récupérer les modifications. édité pour ajouter Il ne serait pas particulièrement difficile de construire une extrémité avant qui pourrait éditer ce fichier et fournir un bouton qui exécute un script pour redémarrer Apache. < / p> : valeur ...
Cette solution ne fonctionne pas car seules les technologies peuvent modifier des fichiers sur le serveur et / ou redémarrer l'Apache.
Il ne serait pas particulièrement difficile de construire une extrémité avant qui pourrait éditer ce fichier et fournir un bouton qui exécute un script pour redémarrer Apache.
@Daniel - Bien que à ce moment-là, vous entrez dans le même type de niveau de travail que les dsbettings exigent.
Si vous devez éviter les redémarrages du serveur, un lieu logique pour les paramètres est la base de données comme Dominic et Daniel a dit, mais vous devrez invalider l'objet Paramètres mis en cache chaque fois qu'il est mis à jour.
On dirait qu'il est possible de re -Set valeurs dans la cache avec faible Niveau Cache API . Tout ce que vous voulez devoir être réalisable avec ces appels:
modèles.py admin.py extras.py template.html
+1 Parce que sachant que cela pourrait faciliter la gestion des projets Django dans VCS. Les développeurs doivent faire attention à ne pas valider des modifications locales aux paramètres. Sinon.
La mise en cache va atténuer cela (lorsque les paramètres locaux sont placés dans la base de données) à une seule requête par instance de processus Django.
Pour redémarrer le serveur afin de recharger les paramètres, vous pouvez simplement appeler le fichier "Touch Site.WSGI", par exemple Avec un travail cron, mais cela ne fonctionnera que si votre processus WSGI fonctionne en mode Daemon.
Cela pourrait aider à donner quelques exemples du type de paramètres d'administrateur dont vous parlez.
paramètres.py est destiné à la configuration du temps de déploiement, il existe évidemment une incompatibilité d'impédance avec ce que vous essayez de faire au moment de l'exécution. Soulevant complètement une solution axée sur la base de données, semble être une optimisation prématurée pour moi.