среда, 31 марта 2010 г.

Администрируемые настроечки и github

Понадобились тут для приложения настраиваемые настройки в админке (буквально потребовалось сделать редактируемыми адреса для отрпавки определённых формочек). Не желая изобретать свой велосипед, полез в гугл. Там обнаружил с ходу старенький django-dbsettings, который мне показался каким-то не кузявым: проект заброшен (хотя есть форки на github) да и с ходу не нашёл там группировки настроек (адреса и сабжи отличаются для разных форм). Следующим оказался совсем свежий django-appsettings. Вроде бы простое приложение, но я что-то 2 вечера разбирался в (ещё не очень знакомых мне) фокусах с метапрограммированием на python, которые там используются. Всему виной, по-моему, несколько противоречивое README к проекту. Ключевым вопросом стало то, что для подключения настроек для приложения необходимо, чтобы эти настройки были использованы в моделях приложения, т.е. в них должны присутствовать строки:

from appsettings import app
settings = app.settings.your_app

которые и вызывают соответствующий autodiscover().
С учётом этого всё стало довольно прозрачно и ясно и группировки вроде на месте, только вот в интерфейсе администрирования их не было у Джареда. Пришлось "форкнуть" проект и реализовать то, что необходимо.
Поставил в итоге ещё один плюсик гиту и понравился github. Правда в последнем обнаружилось пару багов: с коммитом, начинающимся с # он по ходу дела не дружит (в итоге пришлось делать merge из коммандной строки), да ещё на 1-м из флэшевых графов мой Firefox просто "схлопнулся". А в целом очень удобно - возьму себе на вооружение.
P.S. Ещё для настроек есть какое-то решение от авторов Satchmo, но смотреть его как-то было уже лень, когда было получено практически рабочее решение.

вторник, 23 марта 2010 г.

Работать надо меньше...

Минут пятнадцать сидел и "тупил" по поводу того, почему Джанго не хочет переводить строчку, когда локализация к ней написана и скомпилирована. Оказалось, что надо было просто лишь перегрузить девсервер.
Кстати, по поводу локализации: в грядущей версии 1.2 появится новый флажок с говорящим за себя названием - USE_L10N.

суббота, 20 марта 2010 г.

Разделяй и не властвуй?

Эксперименты показывают (в исходники самой Джанго пока не залезал толком), что Django Template Language имеет один не совсем неочевидный ньюанс: переменные, которые устанавливаются с помощью templatetag'ов в блоках, не "шарятся" между разными блоками. В итоге получается, что их надо устанавливать переменные заново в каждом из блоков, т.е. получаем как минимум лишний вызов, и возможно ещё и совершенно лишний запрос к базе.
Можно, конечно, результаты запроса кэшировать, если есть необходимось, но всё равно дублирование остаётся. С другой стороны, безусловно, установка переменных из шаблона не есть правильный подход, всё должно быть установлено по возможности на уровне view или в middleware. Но вот данные нужны на уровне именно самого шаблона, view находятся, в ныеншнем случае, в django CMS, а шаблоны могут туда передаваться разные, данные же эти нужны лишь в одном из них.
Получается или я что-то реально недопонимаю или всё выглядит немного некрасиво.

четверг, 11 марта 2010 г.

Советская власть и русификация всей страны

Обнаружил тут вдруг, что, несмотря на довольно хорошую поддержку интернационализации в Джанго, с локализацией не всё так тривиально, как хотелось бы. По сути надо было решить очень простую задачу - выводить локализованные имена месяцев в архиве новостей (хотя кто знает, что там дальше понадобится ещё). Есть, конечно, datetime.strftime, только вот он пляшет от текущей локали, которая задаётся на весь процесс и не управляется Джанго. В итоге поставил BabelDjango и использовал format_date(date, 'LLLL') оттуда.