使用djangorecipe管理你的项目

如果你正在编写一个新的应用程序，这个方法可以让你在项目之外非常容易地测试它 它允许你管理项目的依赖关系(例如，它应该依赖于哪个版本的应用程序)

你要做的就是这样开始:

Create a folder for your new website (or library) Create a buildout.cfg with following content in it: [buildout] parts=django [django] recipe=djangorecipe version=1.1.1 project=my_new_site settings=development Grab a bootstrap.py to get a local installation of buildout and place it within your directory. You can either go with the official one (sorry, Markdown didn't like part of the full link :-/ ) or with one that uses distribute instead of setuptools as described by Reinout van Rees. python bootstrap.py (or python bootstrap_dev.py if you want to use distribute). ./bin/buildout

就是这样。现在你应该有一个新的文件夹“my_new_site”，这是你新的django 1.1.1项目，在。/bin中你会找到django-script，它取代了正常安装的manage.py。

有什么好处?假设你想在你的项目中使用django-comment-spamfighter之类的东西。你所要做的就是把build - out.cfg修改成这样:

[buildout]
parts=django

[django]
recipe=djangorecipe
version=1.1.1
project=my_new_site
settings=development
eggs=
    django-comments-spamfighter==0.4

请注意，我所做的只是添加了最后两行，表示django部分在0.4版中也应该有django-comments-spamfighter包。下次运行。/bin/buildout时，buildout将下载该包并修改。bin/django，将其添加到其PYTHONPATH中。

Djangorecipe也适用于用mod_wsgi部署你的项目。只需将wsgi=true设置添加到build - out.cfg中的django-part和“django. cfg”。Wsgi "将出现在你的。/bin文件夹中:-)

如果您将测试选项设置为应用程序列表，djangorecipe将为您创建一个漂亮的包装器，为项目中列出的应用程序运行所有测试。

如果你想在一个独立的环境中开发一个单独的应用程序进行调试等，Jakob Kaplan-Moss在他的博客上有一个相当完整的教程

使用django-annoying的render_to装饰器而不是render_to_response。

@render_to('template.html')
def foo(request):
    bars = Bar.objects.all()
    if request.user.is_authenticated():
        return HttpResponseRedirect("/some/url/")
    else:
        return {'bars': bars}

# equals to
def foo(request):
    bars = Bar.objects.all()
    if request.user.is_authenticated():
        return HttpResponseRedirect("/some/url/")
    else:
        return render_to_response('template.html',
                              {'bars': bars},
                              context_instance=RequestContext(request))

编辑后指出，返回一个HttpResponse(例如重定向)将使装饰器短路，并像您期望的那样工作。

如果你还没读过《Unbreaking Django》。它包含了很多关于django陷阱的有用信息。

刚刚找到这个链接:http://lincolnloop.com/django-best-practices/#table-of-contents -“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注入攻击可能造成的损害(尽管您仍然应该检查和过滤所有用户输入)。

(摘自我对另一个问题的回答)

上下文处理器非常棒。

假设你有一个不同的用户模型，你想包括 在每个回应中。不要这样做:

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模型 并在保存后执行它。