Fork me on GitHub
11/2/2008

Werkzeug, Jinja и все-все-все

Давно хотел попробовать Colubrid на пару с Jinja. Теперь у Colubrid есть преемник - Werkzeug, от той же Pocoo team. И Jinja с той поры сильно поменялся, но обо всём по-порядку.

Предыстория

Пару недель назад при разговоре с Александром Соловьевым вспомнился небольшой проект годовой давности на Django с хитрыми SQL-запросами, где вместо изменения структуры данных я тогда нагородил огород с генерацией SQL-запросов. И буквально через пару дней после разговора встала задача сделать ревизию этого проекта. У меня были наметки, как получше сделать этот проект, но пришлось бы сильно менять структуры данных и код, так что было решено, что переписать с нуля будет проще. Я как раз подыскивал проект для пробы Werkzeug и эта задача легла очень хорошо: ни аутентификации, ни обработки форм.

Компоненты конечного приложения выглядели так: Portable Python 1.0, SQLAlchemy 0.4.2, Werkzeug 0.2dev, Jinja 1.3dev. Теперь о компонентах поподробнее.

SQLAlchemy

Версия 0.4 мне понравилась намного больше чем 0.3. В старой версии у меня не получалось выстроить логичной картины, где используется orm, а где sql-kit. В новой версии всё разделено, так что стало всё более прозрачно, на мой взгляд. Вещи, которые прилично помогли: маппинг на объединенные таблицы, интроспекция запросов, совместимость критериев выборки в orm и sql-kit. Благодаря этим возможностям SQLAlchemy, код вьюшек сильно упростился, плюс удалось вынести общий код в отдельный модуль. Тут, конечно, еще сильно повлиял редизайн приложения: я отказался от нормализации данных, усложнив код загрузки данных в БД, но упростив вьюшки.

Werkzeug

Werkzeug пока темная лошадка среди питонистов, так что об этом инструменте я расскажу чуть подробнее.

Werkzeug - это компактный (чуть менее 10k строк) WSGI-тулкит. Что он дает: request/response-объекты, http-exceptions, отладку в браузере, http-сервер с автоперезагрузкой, юнит-тесты для WSGI-приложения, threadsafe менеджер локальных даных, вспомогательные утилиты для работы с WSGI-environ, роутинг запросов. Из всего этого наиболее "вкусное" - это отладка, про которую уже писал Александр Соловьев, и роутинг запросов. Очень понравилось то, что Werkzeug работает не с Python-объектами как конечными точками роутинга, а с некоторой абстракцией - endpoint. Преобразования URL?endpoint и endpoint?URL берет на себя Werkzeug, а endpoint?py-callable и py-callable?endpoint - разработчик приложения. Такой подход дает необычайную гибкость. Что еще хорошо: в примерах к Werkzeug есть best-practice - назначение URLов декораторами (в своем приложении я использовал именно этот способ), web.py-like, routes-like; так что можно взять готовый рецепт, или написать свой.

Jinja

Почти все компоненты мне понравились, отличился Jinja. Мою фразу "Jinja - это правильные Django templates" можно применить разве что к Jinja до версии 1.0. После версии 0.9 это уже другой движок с таким же именем. Попробовав Jinja 1.3dev, скажу, что от Django templates остался только базовый синтаксис {% expression %}, {{ value }}. У Django templates есть масса достоинств, и не так много недостатков. Jinja, на мой взгляд, похоронил все достоинства, плюс приобрел кучу собственных недостатков. Уж лучше Mako - хотя бы нет ложных аналогий с Django templates.

Итоги

Werkzeug хорош. Хорош для тех задач, где фреймворк избыточен (еще бы правильно определить, избыточен ли Django для текущей задачи (-: ). На голову выше Paste: удобней, компактнее, логичней - хотя и не перекрывает всех возможностей Paste. Про SQLAlchemy сомнений никаких не было - наиболее гибкий ORM из существующих, тем более в версии 0.4 его прилично "причесали". А вот Jinja - вообще не вариант.

Комментарии

Все статьи