【发布时间】:2011-09-25 14:28:15
【问题描述】:
我想向管理界面公开一些(特定于应用程序的)设置,以便用户可以轻松地更改它们而不必重新启动 Django。
我该怎么办?
我查看了http://djangopackages.com/grids/g/live-setting/ 上的应用程序(顺便说一句,django-constance 是最吸引人的),但实际上所有这些应用程序所做的是将值存储在数据库中,提供更改它们的 Web 界面和缓存。前两个功能不是已经内置到 Django 中了吗?
我看到的最大缺点是没有一个应用程序可以直接替换这些设置的旧位置 (settings.py),并且需要我迁移到它们的符号,并且经常添加另一个上下文处理器来访问它们在模板中。
我不能这样做吗?
- 为我的设置创建一个模型(这为我提供了各种类型和验证)
- 实例化一个这样的对象来保存我的设置(这允许用户在管理界面中编辑它们) - 我可以像其他模型一样将默认设置转储为固定装置
- 包装 settings.py 以便对我的设置进行数据库查询 - http://www.loose-bits.com/2011/04/extending-django-settings-with-derived.html
从我目前幼稚的角度来看,我看到的唯一缺点是:
- 添加或更改可用设置需要架构迁移(南)。 - 我可以忍受。
- 我有一个可能有多个实例的模型,但实际上只需要一个单例。 - 在某些时候这实际上可能是一个有用的功能。
- 性能/缓存:看看http://code.djangoproject.com/svn/django/trunk/django/conf/,我必须在设置包装器和/或模型中加入一点小技巧,以便模型更改清除或更新缓存值。 - 似乎不是火箭科学。
- 在另一个项目中做同样的事情需要再次进行类似的工作。 - 我认为 settings.py 中的单个字典常量,用于查找的模型名称和字段名称是唯一不同的。
这难道不是两全其美 - 运行时管理员(及其所有特权)、数据库后端、缓存以及我的任何设置。USED_TO_BE_IN_SETTINGS_DOT_PY 不需要任何更改。我错过了什么吗?
【问题讨论】:
-
如果你想像以前那样使用
django.conf.settings,除了破解 Django 本身之外,你没有办法实现你想要的。您应该至少将调用迁移到设置(代码迁移)以使用外部库提供的设置对象。 -
感谢您的评论。使用 settings.py 包装器(请参阅 URL)并没有破解 Django 本身恕我直言,这只是 settings.py 从项目返回设置的方式(但是它们随后被处理)。添加另一个应用程序并重写所有导入似乎比我的方法更有效,我想知道为什么这种方法不够或不能达到我目前预测的效果......
-
也许我误解了你,但是示例包装器不一样,你仍然需要将导入重写为设置吗?不久前我写了一个这样的应用程序(公司内部,所以很遗憾我还不允许发布它),它写了一个围绕设置的包装器。而不是
from django.conf import settings,那么在我使用它的应用程序中它将是from my_settings_app import settings。在这种情况下,最后一个是访问 db/cache 并在它们都不存在时回退到默认设置。这不是你的意思吗? -
这就是我的意思,但我还不明白为什么我不能对 settings.py 本身做同样的事情——它是一个 python 模块。
-
(供将来参考)问题中的网址不再有效,但有效(截至目前)网址为djangopackages.com/grids/g/live-setting