Я хотел бы предоставить некоторые (специфичные для приложения) настройки интерфейсу администратора, чтобы пользователи могли их удобно менять, а также не нужно было перезапускать Django.
Как мне поступить?
Я проверил приложения на http://djangopackages.com/grids/g/live-setting/ (кстати, django-constance был наиболее привлекательным), но на самом деле все эти приложения делают хранение значений в базе данных, предоставляя веб-интерфейс для их изменения, икэширование.Разве первые две функции уже не встроены в Django?
Самые большие недостатки, которые я вижу, заключаются в том, что ни одно из приложений не является заменой старого расположения этих настроек (settings.py) и требует от меняперейти к их записи и часто добавлять другой контекстный процессор для доступа к ним в шаблонах.
Не могу ли я просто сделать это?
- Создать модель для моих настроек (это даетмне различные типы и проверки)
- Создание одного такого объекта для хранения моих настроек (это позволяет пользователям редактировать их в интерфейсе администратора) - я мог бы сбрасывать значения по умолчанию как приборы, как для других моделей
- Заверните файл settings.py, чтобы он выполнял запрос базы данных для моих настроек - http://www.loose -bits.com / 2011/04 / extending-django-settings-with-производный.html
С моей текущей, наивной точки зрения единственными недостатками, которые я вижу, будет:
- Добавление или изменение доступных настроек требует переноса схемы (на юг).- Я могу жить с этим.
- У меня есть модель, возможно, с несколькими экземплярами, но на самом деле мне нужен только синглтон.- В какой-то момент это может быть полезной функцией.
- Производительность / Кэширование: Глядя на http://code.djangoproject.com/svn/django/trunk/django/conf/ Мне бы пришлось немного поразмыслить в обертке настроек и / или модели,так что модель меняет очистить или обновить кэшированные значения.- не похоже на ракетостроение.
- Чтобы сделать то же самое в другом проекте, снова потребуются аналогичные усилия.- Я думаю, что единственная словарная константа в settings.py, содержащая названия моделей и имена полей для поиска, - это все, что будет отличаться.
Разве это не будет лучшим из обоих миров -администратор времени выполнения (со всеми его привилегиями), серверная часть базы данных, кэширование и ни один из моих параметров .USED_TO_BE_IN_SETTINGS_DOT_PY потребуется изменить.Я что-то упустил?