Любимая Django Tips & Features?

Just found this link: http://lincolnloop.com/django-best-practices/#table-of-contents - "Django Best Practices".

Используйте сигналы для добавления методов доступа на лету.

Я видел эту технику в django-photologue : для любого добавленного объекта размера сигнал post_init добавит соответствующие методы модели Image. Если вы добавите сайт гигант , методы для получения изображения с гигантским разрешением будут image.get_giant_url () .

Методы создаются путем вызова add_accessor_methods из сигнала post_init :

def add_accessor_methods(self, *args, **kwargs):
    for size in PhotoSizeCache().sizes.keys():
        setattr(self, 'get_%s_size' % size,
                curry(self._get_SIZE_size, size=size))
        setattr(self, 'get_%s_photosize' % size,
                curry(self._get_SIZE_photosize, size=size))
        setattr(self, 'get_%s_url' % size,
                curry(self._get_SIZE_url, size=size))
        setattr(self, 'get_%s_filename' % size,
                curry(self._get_SIZE_filename, size=size))

См. исходный код photologue.models для реального использования.

Use djangorecipe to manage your project

• If you're writing a new app, this recipe makes testing it outside of a project really easy
• It allows you to manage dependencies for a project (e.g. what version of some app it should depend on)

All you have to do to get started is this:

1. Create a folder for your new website (or library)

2. 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
   

3. 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.
4. python bootstrap.py (or python bootstrap_dev.py if you want to use distribute).
5. ./bin/buildout

That's it. You should now have a new folder "my_new_site", which is your new django 1.1.1 project, and in ./bin you will find the django-script which replaces the manage.py on a normal installation.

What's the benefit? Let's say you want to use something like django-comment-spamfighter in your project. All you'd have to do is change your buildout.cfg to something like this:

[buildout]
parts=django

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

Note that all I did was to add the last 2 lines which say, that the django-part should also have the django-comments-spamfighter package in version 0.4. The next time you run ./bin/buildout, buildout will download that package and modify ./bin/django to add it to its PYTHONPATH.

djangorecipe is also suited for deploying your project with mod_wsgi. Just add the wsgi=true setting to the django-part of your buildout.cfg and a "django.wsgi" will appear in your ./bin folder :-)

And if you set the test option to a list of applications, the djangorecipe will create a nice wrapper for you that runs all the tests for the listed application in your project.

If you want to develop a single app in a standalone environment for debugging etc., Jakob Kaplan-Moss has a quite complete tutorial on his blog

Вместо того, чтобы запускать сервер разработки Django на локальном хосте, запустите его на правильном сетевом интерфейсе. Например:

python manage.py runserver 192.168.1.110:8000

или

python manage.py runserver 0.0.0.0:8000

Тогда вы можете не только легко использовать Fiddler ( http://www.fiddler2.com/fiddler2/ ) или другой инструмент, например HTTP Debugger ( http: //www.httpdebugger.com/) для проверки ваших HTTP-заголовков, но вы также можете получить доступ к своему сайту разработчика с других компьютеров в вашей локальной сети для тестирования.

Убедитесь, что вы защищены брандмауэром, хотя dev-сервер минимален и относительно безопасен.

Это действительно простой способ больше никогда не импортировать еще одну из ваших моделей в оболочку python.

Сначала установите IPython (если вы этого не сделаете) Я не использую IPython, что с тобой?). Затем создайте сценарий python ipythonrc.py в каталоге проекта django со следующим кодом:

from django.db.models.loading import get_models 
for m in get_models(): 
     globals()[m.__name__] = m 
#NOTE: if you have two models with the same name you'll only end up with one of them

Затем в файле ~ / .ipython / ipythonrc поместите следующий код в «Файлы Python для загрузки и execute "section:

execfile /path/to/project/ipythonrc.py

Теперь каждый раз, когда вы запускаете IPython или ./ manage.py shell , все ваши модели будут уже импортированы и готовы к использованию. Больше не нужно импортировать другую модель.

Вы также можете поместить любой другой код, который вы часто выполняете, в свой файл ipythonrc.py, чтобы сэкономить время.

Используйте декоратор обертки в декораторах пользовательских представлений, чтобы сохранить имя представления, модуль и строку документации. Например.

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

Остерегайтесь : не будет работать с представлениями на основе классов (те, у которых есть определение метода __ call __ ), если автор не определил свойство __ name __ . В качестве временного решения используйте:

from django.utils.decorators import available_attrs
...
    @wraps(fun, assigned=available_attrs(fun))

Изменение свойств поля формы Django при инициализации

Иногда бывает полезно передать дополнительные аргументы классу формы.

from django import forms
from mymodels import Group

class MyForm(forms.Form):
    group=forms.ModelChoiceField(queryset=None)
    email=forms.EmailField()
    some_choices=forms.ChoiceField()


    def __init__(self,my_var,*args,**kwrds):
        super(MyForm,self).__init__(*args,**kwrds)
        self.fields['group'].queryset=Group.objects.filter(...)
        self.fields['email'].widget.attrs['size']='50'
        self.fields['some_choices']=[[x,x] for x in list_of_stuff]

источник: фрагменты Dzone

Django Debug Toolbar Django Debug Toolbar - это действительно фантастика. Это не совсем панель инструментов, на самом деле она вызывает боковую панель, которая сообщает вам всевозможную информацию о том, что привело вас к странице, на которую вы смотрите - запросы к БД, контекстные переменные, отправленные в шаблон, сигналы и многое другое.

Используйте reverse в urlconf.

Это один из тех приемов, когда я не понимаю, почему он не используется по умолчанию.

Вот ссылка на то, где я это взял: http://andr.in/2009/11/21/calling-reverse-in-django/

Вот фрагмент кода:

from django.conf.urls.defaults import *
from django.core.urlresolvers import reverse
from django.utils.functional import lazy
from django.http import 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')
)