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ов декораторами (в своем приложении я использовал именно этот способ), , 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 — вообще не вариант.

Подписаться Комментировать

Комментарии

11.02.2008 10:06 undebugger
А поподробнее про недостатки jinja можно? Мне, например, понравилось. В Mako же тот недостаток, что имена переменных шаблона смешаны с locals(), причём locals() выбираются первыми, и от этого получаются всякие неожиданности — например, нет никакого способа иметь переменную шаблона с названием id (потому что подставляется имя соответствующей встроенной функции).
11.02.2008 10:24 Max Ischenko
Спасибо за наводку. Я вот все жду когда эти ребята свой форум релизнут. Но они, похоже, как Кнут, решили начать с самого начала. ;)
12.02.2008 7:11 kleptos
А что не так с web.py?
12.02.2008 7:38 deepwalker
Вот я сисадмин вообще то, но обожаю читать блоги питонистов — как вы любите все причесывать и идти самым правильным путем в мельчайших частностях : ) Видимо это то самое, чего нет у php — сошедших с ума на правильности разработчиков : )

Форма комментирования для «Werkzeug, Jinja и все-все-все»

Обязательное поле. Не больше 30 символов.

Обязательное поле

Пожалуйста, введите символы, которые вы видите на изображении

12.02.2008 11:57 Александр Соловьёв
> как вы любите все причесывать и идти самым правильным путем в мельчайших частностях :) Хе-хе. Да, я тоже замечал такую штуку. Иногда приходится себя сдерживать, чтоб сделать всё, а не до бесконечности вылизывать что-то одно. :-)
14.02.2008 20:01 Юревич Юрий
А поподробнее про недостатки jinja можно? Мне, например, понравилось.
Да дело в том, что с этими недостатками можно мириться, если были бы какие-нибудь выдающиеся фичи. А так получается, средний движок, да еще с ложными аналогиями к Django templates. Это то и убивает. Раньше было “правильные Django templates”, сейчас стало “средненький движок, похожий на Django templates”.
2.02.2009 3:49 Vadim Fint

Неужели в феврале 2008 ещё не было jinja2? На самом деле jinja1 я особо не разглядывал, но jinja2 внутри — имхо самый логично устроенный и сделанный темплейтный движок на питоне. После string.Template, конечно =).

django-темплейты ОЧЕНЬ медленные при 2-3 уровнях вложности. И просто чудовищно медленные при более высоких. (3 уровня вложенности = 1 layout + 1 html extends layout + 1 loop/for/whatether).

4.02.2009 0:08 Юревич Юрий

Неужели в феврале 2008 ещё не было jinja2?

AFAIR, 2.0rc появилось летом 2008.

django-темплейты ОЧЕНЬ медленные при 2-3 уровнях вложности

Охотно верю. Но для меня пока это не критично.

4.02.2009 0:29 Vadim Fint

ну на больших проектах 200мс в темпелейте на запрос против 10-20мс — очень ощутимый прирост, особенно при вылизанной бизнес-логике во вьюшках на которые приходится в сумме ещё 150-200мс.

Я конечно понимаю что вы пишете для себя и тп, но статья жутко не объективна.

4.02.2009 0:30 Vadim Fint

да и подпишите к дате GMT+7 :).

18.02.2008 14:57 undebugger
Да что изменилось-то (ухудшилось)? Я как-то пропустил… По-моему, управляющие структуры — однозначно лучше, чем в Django.
13.04.2008 2:07 slav0nic
cherrypy и web.py мне всё же больше нравятся простотой, а возможнисти всё теже. Werkzeug показался более запутанным и уж слишком много ООП на ровном месте В)
13.04.2008 19:22 Юревич Юрий
Каждому своё.