Gostaria de expor algumas configurações (específicas do aplicativo) à interface do administrador, para que os usuários possam alterá-las confortavelmente e também não precise reiniciar o Djang

Como devo fazer isso?

Fiz o check-out dos aplicativos emhttp: //djangopackages.com/grids/g/live-setting (btw django-constance foi o mais atraente), mas na verdade o que todos esses aplicativos estão fazendo é armazenar valores em um banco de dados, fornecer uma interface da web para alterá-los e armazenar em cache. Os dois primeiros recursos já não estão embutidos no Django?

As maiores desvantagens que vejo são que nenhum dos aplicativos substitui o local antigo dessas configurações (settings.py) e exige que eu migre para a notação deles e frequentemente adicione outro processador de contexto para acessá-los nos modelos .

Eu não poderia simplesmente fazer isso?

rie um modelo para minhas configurações (isso me dá os vários tipos e validaçã Instale um desses objetos para manter minhas configurações (isso permite que os usuários os editem na interface do administrador) - Eu poderia despejar os padrões como acessórios, como em outros modeloWrap settings.py, fazendo uma consulta ao banco de dados para minhas configurações -http: //www.loose-bits.com/2011/04/extending-django-settings-with-derived.htm

Do meu ponto de vista atual e ingênuo, os únicos inconvenientes que vejo seriam:

Adicionar ou alterar as configurações disponíveis requer uma migração de esquema (sul). - Eu posso viver com isso Eu tenho um modelo com várias instâncias, mas realmente preciso apenas de um singleton. - Isso pode realmente ser um recurso útil em algum momento. Desempenho / armazenamento em cache: olhando parahttp: //code.djangoproject.com/svn/django/trunk/django/conf Eu precisaria colocar um pouco de inteligência no wrapper e / ou no modelo de configurações, para que o modelo mude ou limpe os valores em cache. - não parece ser ciência de foguetes.azer o mesmo em outro projeto exigiria um esforço semelhante novamente. - Acho que uma única constante de dicionário em settings.py, mantendo o (s) nome (s) do modelo e os nomes dos campos para as pesquisas, é tudo o que seria diferent

Esse não seria o melhor dos dois mundos - o administrador de tempo de execução (com todas as suas vantagens), o back-end do banco de dados, o cache e nenhuma das minhas configurações.USED_TO_BE_IN_SETTINGS_DOT_PY precisaria de alterações. Estou esquecendo de algo