Джанго в роли микрофреймворка

Известно мнение, что Джанго не подходит для написания "наколеночных" проектиков, которым не нужно ничего особенно, кроме вывода HTML'а. Создание скелета проекта на Джанго считается работой, достаточно существенной для того, чтобы не заниматься ею ради пары функций.

Мне всегда было "очевидно", что это не так, но недавно по оброненной коллегой фразе я понял, что это не значит, что это очевидно всем. Многие просто не задумываются об этом. Ну, вы знаете, как это бывает… Поэтому я хочу продемонстрировать создание Джанго-проекта минимальными усилиями.

Упрощение

1. Нужно отказаться от команды startproject. Она создаёт хороший скелет проекта с аннотированным файлом настроек, но если вы Джанго-проект видите не впервые, этим можно пренебречь.

2. Файл manage.py — тоже не нужен, это просто локальный хелпер для django-admin.py

3. Не нужно думать о проекте, как о контейнере для приложений, а следовательно не нужно оформлять свой код, как подключаемое приложение. Приложения — одна из самых сильных архитектурных черт Джанго, но для мелких задач эта гибкость никогда не понадобится.

В итоге мы имеем что-то такое:

• settings.py:

  DEBUG = True
  ROOT_URLCONF = 'urls'
  TEMPLATE_DIRS = ['.']
  

• urls.py:

  from django.conf.urls.defaults import *
  
  import views
  
  urlpatterns = patterns('',
      (r'^$', views.index),
      (r'^test/(\d+)/$', views.test),
  )
  

• views.py:

  from django.shortcuts import render
  
  def index(request):
      return render(request, 'index.html', {})
  
  def test(request, id):
      return render(request, 'test.html', {'id': id})
  

Это — полностью рабочий Джанго-проект. Запускается командой:

django-admin.py --settings=settings runserver

Вы получаете джанговский конвейер request-response, шаблоны. Также ничто не должно мешать работать такой хорошей вещи, как библиотека форм, хотя реально я не проверял. Что вы теряете — так это ORM и завязанные на него приложения. Но на то эта задача и "микро".

Экстремальщина

Чтобы нащупать границу того, когда идея дойдёт до абсурда, я решил ещё собрать всё приложение в один самозапускающийся файл. И у меня вышло:

• web.py:

  #### Setup
  
  from django.conf import settings
  if not settings.configured:
      settings.configure(
          DEBUG = True,
          ROOT_URLCONF = 'web',
          TEMPLATE_DIRS = ['.'],
      )
  
  from django.conf.urls.defaults import patterns
  urlpatterns = patterns('',
      (r'^$', 'web.index'),
      (r'^test/(\d+)/$', 'web.test'),
  )
  
  #### Handlers
  
  from django.shortcuts import render
  
  def index(request):
      return render(request, 'index.html', {})
  
  def test(request, id):
      return render(request, 'test.html', {'id': id})
  
  #### Running
  
  if __name__ == '__main__':
      from django.core.management import execute_from_command_line
      execute_from_command_line()
  

Файл запускается так:

python web.py runserver

Впрочем, особенной радости от такой сборки я не увидел. Чтобы файл читался, его приходится делить на именованные секции, что как бы говорит нам о том, что это таки должны быть разные файлы. Плюс, написать такой файлик из головы я бы всё равно не смог из-за того что много надо делать по памяти: защита от двойной конфиграции настроек, длинные импорты и т.д.

Но как факт — забавно :-).

Побочная идея

Копаясь с инициализацией проекта я обнаружил, что настройка ROOT_URLCONF используется в самом ядре обработки запроса. Это привязывает работу Джанго к наличию реального модуля с определённой в нём переменной urlpatterns. Джанго была бы гибче, если бы конфигурацию URL'ов можно было инициализировать программно простым списком:

settings.configure(
    DEBUG = True,
    urlconf = [
        (r'^$', index),
    ],
)

Это, наверное, было бы даже полезно на практике, когда среду нужно уметь создавать на лету. Например, при тестировании.