Read-only поля в админке

Релиз 1.2 меня прям радует своей человечностью )
Хотели read-only поля в админке? Получите, распишитесь.

К admin.ModelAdmin добавился новый атрибут: readonly_fields.
В использовании схож с list_display, т.е. можно указать не только поля модели, но и методы объекта админки.

И надо учесть что, если вы не задали порядок в fields или fieldsets, то read-only поля будут идти после обычных.

Человечный SQL

Джанга всегда славилась удобством из коробки, но как только тебе надо чуть больше, чем положено, начинается гемор...
Хороший пример это sql запрос, который стандартный ORM не позволял составить.
Правда, не буду лукавить, есть 2 метода запихивания своего sql в запрос:

1. Обращение к базе минуя ORM
   

   connect.cursor().execute('SELECT * FROM `person`;')

   Большим минусом является, то что на выходе у нас список списков, а не объектов нужной нам модели.
   
2. Дополнение запроса от ORM
   

   Books.objects.filter(pages__gte=123).extra(select={'result': 'SUM(cost)'})

   Тут минус - в ограниченности.
   

Правда, сейчас extra почти не нужен, его земенил annotate.
Но вселенского счастья все равно не наступило )

И тут, ВНЕЗАПНО... ревизия 11921 и Model.objects.raw офигеть! )

Прощай ifequal

Думаю, всех задолбали кострированные темплейты в джанге, но в силу привычки/наличия существующего кода или еще чего люди с них не уходят и продолжают жрать кактус )

Самая простая ситуация:

if len(words) > 10:   print wordselse:   print trim(words)

Решается в джанге ну очень не явным способом )
Писался фильтр типа такого:

def gt(value, count):    return value > count

И использовался, как

{% if word|length|gt:3 %}

Думаю, вы согласитесь это выглядит упячисто (

Конечно, можно было использовать уже готовые решения из снипитов. Но если это надо только на одной странице, то мне очень сильно лень искать и подключать сторонюю библиотеку. Вот если бы все уже было в транке...

Новая система сообщений

Надавно закрылся еще один двух годичный тикет, "session-based messages". И уже давно пора, а то успел понаплодиться зоопарк решений:
http://code.google.com/p/django-notify/
http://djangoflash.destaquenet.com/
http://code.google.com/p/django-session-messages/

Дело в том, что изначально в джанге сообщения можно было создавать только для авторизованных пользователей, чего явно не достаточно. Самое просто решение было складывать мессаги в сессию:

request.session['messages'] = ('Hi user', )

А потом выдергивать в темплейте, думаю, так было сделано не мало велосипедов )

Итак, сейчас у нас есть django.contrib.messages и что приятно они не поломали обратную совместимость )

Template cache

Есть у меня дурная привычка, просматривать svn log джанги по утрам, благодаря которой и появился этот блог, в общем, встречайте первый блин:

Сегодня я хочу поговорить о тормозах, и, как мне кажется, самое медленное место в джанге (помимо кривых рук программистов) это темплейты.

Сам принцип их работы очень напоминает cgi - на каждый запрос мы все делаем заново, заново ищем файл, заново читаем файл (или еще что) и наконец заново компилируем (получаем объект Template).
Конечно на этом работа с темплейтами не заканчивается, сам рендеринг еще не начинался, и основные тормоза как раз в нем, но повторюсь это выполняется на каждый запрос, и это правда не быстро.

Для решения этой проблемы 2 года назад открыли тикет 6262, предлагалось кэшировать темплейты после их первой загрузки, все бы хорошо, и сама задача выглядит не сложной, но есть забавные подводные камни.