Рубрика: Django

responseText ошибки при AJAX-запросе

За формирование страницы ошибки отвечает функция technical_500_response из django.views.debug,
программисты джанги пошли странным путем, жестко задав (без возможности настройки): если запрос AJAX — ответ будет текстом, в остальных случаях HTML.
Все бы ничего, но raise Http404(), например, плевать на этот механизм хотела, и все равно выбрасывает HTML, если выводить ошибку в консоль — сущий ад.
Изменить поведение можно например так:
Добавить Middleware которая, в случае ошибки уберет из request соответствующий заголовок,
дальше джанга отработает по своему алгоритму и вернет красивый HTML.
Криво конечно, т.к. пропадает возможность узнать был Ajax или не было, но не нужно патчить Django

1
2
3
4

class DisableAjaxException(object):
    @staticmethod
    def process_exception(req, exception):
        req.META['HTTP_X_REQUESTED_WITH'] = None

Ну и остается напомнить, порядок Middleware в settings.py важен

MySQL и foreign key constraint fails

Cannot add or update a child row: a foreign key constraint fails
Такое случается, если включена проверка InnoDB foreign key, но ссылается ключ на таблицу не InnoDB (например MyISAM)
лечится:

  • конвертированием всех таблиц в InnoDB
  • конвертирование всех таблиц в MyISAM
  • или отключением проверки:
DATABASES = {
'default': {
    ...         
    'OPTIONS': {
         "init_command": "SET foreign_key_checks = 0;",
    },
 }
}

Статейка про InnoDB

Как использовать Django из внешнего скрипта

Для асинхронной задачи можно создать команду (django management command), или подключить джагну к своему сприпту:

import sys
sys.path.append('/path/to/django/projectname')
from projectname import settings
from django.core.management import setup_environ
setup_environ(settings)
#Получаем настроенную среду django:
from main.models import Model1
print Model1.objects.all()

Админка по-умолчанию для всех моделей

В процессе разработки часто требуется по-быстрому зарегистрировать в админке все модели,
на мой взгляд, самый простой и быстрый способ:
добавить в admin.py:

from django.contrib import admin
import models
 
#Функция возвращающая список моделей в модуле
def list_models(module):
    import inspect
    from django.db import models
    classes = []
    for name, obj in inspect.getmembers(module):
        if inspect.isclass(obj) and issubclass(obj, models.Model):
            classes.append(obj)
    return classes
 
#Регистрируем все модели
for model in list_models(models):
    admin.site.register(model, admin.ModelAdmin)

Ускоряем Django: View на С

Иногда требуются ресурсоемкие вычисления, и узким местом становится именно питон. Тогда на помощь приходит код написанный на C/С++
К счастью питон-модули пишутся довольно просто, и документация с примерами есть на официальном сайте. Никакой америки я сейчас не открою, и если вы когда-нибудь сталкивались с написанием модуля для питона — далее можно не читать — все довольно примитивно.

Читать далее

Django: POST

Тут все предельно просто, параметры POST-запроса парсятся и услужливо складываются в словарь POST объекта request, который всегда передается первым параметром в любой view.
Пример.
Форма

<form method="POST" action="/hello">
<label>Name:</label><input type="text" name="name" />
<input type="submit" /> 
</form>

view обрабатывающий URL /hello:

@csrf_exempt # глушилка защиты CSRF, об этом ниже
def hello(request):
text = ""
 if "name" in request.POST: 
  text = u"Параметр POST передан: привет %s" % request.POST['name']
 else:
  text = u"Параметр POST не передан"
 return HttpResponse(text)

Читать далее

Django. Передача GET-параметров

В продолжении Личное: Django. От простого

Научим приложение main здороваться с конкретным человеком. Для этого нужно в представление сообщить имя этого человека: модифицируем наше представление:

def hello(Response, name='World'):
 return HttpResponse("Hello %s!" %name)

Теперь функция представления принимает один необязательный аргумент name
Добавим привязку в urls.py

url(r'^(\w+)$', 'main.views.hello'),

Подробнее с регулярными выражениями можно познакомиться в документации на Python http://docs.python.org/2/library/re.html

В случае совпадения URL с данным регулярным выражением, Django вытащит группу указанную в скобках \w+ в качестве второго параметра функции представления: например запрос

http://127.0.0.1:8000/User
приведет к вызову

hello(Request,"User")

И страничка поздоровается c User:

Hello User!

Django. От простого

В продолжении Django. Структура проекта.

Итак проект создан — и уже работает, можно запустить development сервер и посмотреть, что получилось:

$ ./manage.py runserver
Validating models...

0 errors found
Django version 1.4.3, using settings 'first.settings'
Development server is running at http://127.0.0.1:8000/
Quit the server with CONTROL-C.

Здесь видно что сервер запустился на loopback интерфейсе на порту 8000. Использование loopback-интерфейса по-умолчанию кроет в себе некий смысл:
development-сервер можно (и нужно) использовать только для разработки проекта.
Читать далее

Django. Структура проекта.

Все нижеописанное отностится к версии django-1.4, в 1.3 и ниже есть некоторые отличия.

Основная причина недоумения и непонимания людей всю жизнь видевших только PHP фреймворки в как раз в структуре проекта и принципах работы фреймворка Django. Я надеюсь после прочтения туман рассеется и ориентироваться станет много проще.
Читать далее