灵感来自问题系列的隐藏特征…,我很想听听你最喜欢的Django技巧或你知道的不太为人所知但有用的功能。
请在每个答案中只包含一个技巧。 添加Django版本要求(如果有的话)。
灵感来自问题系列的隐藏特征…,我很想听听你最喜欢的Django技巧或你知道的不太为人所知但有用的功能。
请在每个答案中只包含一个技巧。 添加Django版本要求(如果有的话)。
当前回答
从settings.py中删除数据库访问信息
我在Django站点的settings.py中做的一件事是从/etc文件中加载数据库访问信息。这样,每台机器的访问设置(数据库主机、端口、用户名、密码)都是不同的,并且像密码这样的敏感信息不在我的项目存储库中。您可能希望以类似的方式限制对工作者的访问,即让他们使用不同的用户名连接。
您还可以通过环境变量传递数据库连接信息,甚至只是一个配置文件的键或路径,并在settings.py中处理它。
例如,下面是我如何拉入我的数据库配置文件:
g = {}
dbSetup = {}
execfile(os.environ['DB_CONFIG'], g, dbSetup)
if 'databases' in dbSetup:
DATABASES = dbSetup['databases']
else:
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.mysql',
# ...
}
}
不用说,你需要确保DB_CONFIG中的文件除了db管理员和Django本身外,其他用户都不能访问。默认情况下,Django应该参考开发人员自己的测试数据库。使用ast模块代替execfile可能还有更好的解决方案,但我还没有研究过。
我做的另一件事是为DB管理任务使用单独的用户。在我的manage.py中,我添加了以下序言:
# Find a database configuration, if there is one, and set it in the environment.
adminDBConfFile = '/etc/django/db_admin.py'
dbConfFile = '/etc/django/db_regular.py'
import sys
import os
def goodFile(path):
return os.path.isfile(path) and os.access(path, os.R_OK)
if len(sys.argv) >= 2 and sys.argv[1] in ["syncdb", "dbshell", "migrate"] \
and goodFile(adminDBConfFile):
os.environ['DB_CONFIG'] = adminDBConfFile
elif goodFile(dbConfFile):
os.environ['DB_CONFIG'] = dbConfFile
其中/etc/django/db_regular.py中的配置是针对只有SELECT, INSERT, UPDATE, DELETE权限的Django数据库用户,而/etc/django/db_admin.py中的配置是针对拥有CREATE, DROP, INDEX, ALTER, LOCK TABLES权限的用户。(迁移命令来自南方。)这在运行时为我提供了一些保护,防止Django代码弄乱我的模式,并限制了SQL注入攻击可能造成的损害(尽管您仍然应该检查和过滤所有用户输入)。
(摘自我对另一个问题的回答)
其他回答
当Django和另一个应用程序交换数据时,请求。Raw_post_data是一个好朋友。使用它来接收和自定义处理(比如XML数据)。
文档: http://docs.djangoproject.com/en/dev/ref/request-response/
我就从我自己的一个建议开始吧:)
在settings.py中使用os.path.dirname()来避免硬编码的dirname。
如果你想在不同的位置运行你的项目,不要在你的settings.py中硬编码路径。如果你的模板和静态文件位于Django项目目录中,在settings.py中使用下面的代码:
# settings.py
import os
PROJECT_DIR = os.path.dirname(__file__)
...
STATIC_DOC_ROOT = os.path.join(PROJECT_DIR, "static")
...
TEMPLATE_DIRS = (
os.path.join(PROJECT_DIR, "templates"),
)
工作人员:我从视频《Django from the Ground Up》中得到了这个提示。
在urlconf中使用reverse。
这是我不明白为什么它不是默认的那些技巧之一。
这里有一个链接到我拿起它的地方: http://andr.in/2009/11/21/calling-reverse-in-django/
下面是代码片段:
从django.conf.urls.defaults导入* 从django.core.urlresolvers导入反向 从django.utils.functional导入lazy django。http导入HttpResponse Reverse_lazy = lazy(reverse, str) Urlpatterns = patterns(", url(r'^comehere/', lambda request: HttpResponse('Welcome!'), name='comehere'), url (r“^ $”,“django.views.generic.simple.redirect_to”, {'url': reverse_lazy('comehere')}, name='root') )
在我的站点模板中,我使用了一组自定义标记。寻找一种自动加载的方法(DRY,记得吗?),我发现如下:
from django import template
template.add_to_builtins('project.app.templatetags.custom_tag_module')
如果你把它放在一个默认加载的模块中(例如你的主urlconf),你将有来自自定义标签模块的标签和过滤器在任何模板中可用,而不需要使用{% load custom_tag_module %}。
传递给template.add_to_builtins()的参数可以是任何模块路径;您的自定义标记模块不必存在于特定的应用程序中。例如,它也可以是项目根目录中的一个模块。“project.custom_tag_module”)。
在自定义视图装饰器中使用wraps装饰器来保留视图的名称、模块和文档字符串。如。
try:
from functools import wraps
except ImportError:
from django.utils.functional import wraps # Python 2.3, 2.4 fallback.
def view_decorator(fun):
@wraps(fun)
def wrapper():
# here goes your decorator's code
return wrapper
注意:如果作者没有定义__name__属性,则在基于类的视图(具有__call__方法定义的视图)上无效。作为一种变通方法:
from django.utils.decorators import available_attrs
...
@wraps(fun, assigned=available_attrs(fun))