灵感来自问题系列的隐藏特征…,我很想听听你最喜欢的Django技巧或你知道的不太为人所知但有用的功能。
请在每个答案中只包含一个技巧。 添加Django版本要求(如果有的话)。
灵感来自问题系列的隐藏特征…,我很想听听你最喜欢的Django技巧或你知道的不太为人所知但有用的功能。
请在每个答案中只包含一个技巧。 添加Django版本要求(如果有的话)。
当前回答
我从sorl-thumbnails应用程序的文档中学到了这一点。你可以在模板标签中使用“as”关键字来在模板的其他地方使用调用的结果。
例如:
{% url image-processor uid as img_src %}
<img src="{% thumbnail img_src 100x100 %}"/>
这一点在Django templatetag文档中提到过,但仅用于引用循环。他们并没有说你也可以在其他地方使用它(任何地方?)
其他回答
上下文处理器非常棒。
假设你有一个不同的用户模型,你想包括 在每个回应中。不要这样做:
def myview(request, arg, arg2=None, template='my/template.html'):
''' My view... '''
response = dict()
myuser = MyUser.objects.get(user=request.user)
response['my_user'] = myuser
...
return render_to_response(template,
response,
context_instance=RequestContext(request))
上下文过程使您能够将任何变量传递给您的 模板。我通常把我的放在'my_project/apps/core/context.py中:
def my_context(request):
try:
return dict(my_user=MyUser.objects.get(user=request.user))
except ObjectNotFound:
return dict(my_user='')
在settings.py中,将以下行添加到TEMPLATE_CONTEXT_PROCESSORS中
TEMPLATE_CONTEXT_PROCESSORS = (
'my_project.apps.core.context.my_context',
...
)
现在每次请求都会自动包含my_user键。
这也是胜利的信号。
几个月前我写了一篇关于这方面的博客文章,所以我只是要剪切和粘贴:
开箱即用的Django提供了几个信号 令人难以置信的有用。你有能力提前做好事情 发布保存,初始化,删除,甚至当请求正在进行时 处理。我们先不讲概念 演示如何使用这些。假设我们有一个博客
from django.utils.translation import ugettext_lazy as _
class Post(models.Model):
title = models.CharField(_('title'), max_length=255)
body = models.TextField(_('body'))
created = models.DateTimeField(auto_now_add=True)
所以你想要通知众多博客中的一个 服务我们已经做了一个新的帖子,重建最近 帖子缓存,并tweet关于它。你有信号 无需添加任何内容即可完成所有这些操作的能力 方法添加到Post类。
import twitter
from django.core.cache import cache
from django.db.models.signals import post_save
from django.conf import settings
def posted_blog(sender, created=None, instance=None, **kwargs):
''' Listens for a blog post to save and alerts some services. '''
if (created and instance is not None):
tweet = 'New blog post! %s' instance.title
t = twitter.PostUpdate(settings.TWITTER_USER,
settings.TWITTER_PASSWD,
tweet)
cache.set(instance.cache_key, instance, 60*5)
# send pingbacks
# ...
# whatever else
else:
cache.delete(instance.cache_key)
post_save.connect(posted_blog, sender=Post)
好了,通过定义这个函数并使用 post_init信号,将函数连接到Post模型 并在保存后执行它。
Instead of using render_to_response to bind your context to a template and render it (which is what the Django docs usually show) use the generic view direct_to_template. It does the same thing that render_to_response does but it also automatically adds RequestContext to the template context, implicitly allowing context processors to be used. You can do this manually using render_to_response, but why bother? It's just another step to remember and another LOC. Besides making use of context processors, having RequestContext in your template allows you to do things like:
<a href="{{MEDIA_URL}}images/frog.jpg">A frog</a>
这是非常有用的。事实上,+1在一般的视图上。对于简单的应用程序,Django文档大多将它们作为快捷方式显示,甚至没有views.py文件,但你也可以在自己的视图函数中使用它们:
from django.views.generic import simple
def article_detail(request, slug=None):
article = get_object_or_404(Article, slug=slug)
return simple.direct_to_template(request,
template="articles/article_detail.html",
extra_context={'article': article}
)
PyCharm IDE是一个很好的编码环境,尤其是调试环境,内置了对Django的支持。
Django调试工具栏真的很棒。它实际上并不是一个工具栏,而是一个侧栏,告诉您是什么带来了您正在查看的页面的各种信息——DB查询、发送到模板的上下文变量、信号等等。
从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注入攻击可能造成的损害(尽管您仍然应该检查和过滤所有用户输入)。
(摘自我对另一个问题的回答)