Велосипед для веб-фреймворка

Макс Ищенко решил не следовать моему совету выбрать Django для веб-разработки и выбрал TurboGears :-). Ни в коем случае не хочу как-то спорить с этим решением: может быть миллион причин выбрать то или это. Вместо этого я, как пропагандист Django, хочу прокомментировать то, как он обосновал свое решение в двух следующих постах.

Вот цитата:

... разработчик(и) TurboGears не стали изобретать велосипед, а взяли готовые, зарекомендовавшие себя компоненты: MochiKit, Kid, CherryPy, SQLObject. Это дает не только внушительный объем функциональности, но и доступ к сложившимся вокруг этих проектов коммьюнити.

Классический случай изобретения велосипеда — это когда некий программист, смотря на какую-то библиотеку, говорит себе: "и зачем такие сложности?" и начинает лепить что-то свое, безусловно "правильное" и "эффективное". Потом оказывается, что в задаче, которую он решает, гораздо больше сложностей и неочевидностей, чем было видно в начале. И выходит, что вся та сложность в написанных решениях есть не просто так, а соответствует реальности. В итоге получается, что новое решение получается таким же кривым и волосатым, но зато у него не хватает половины функциональности, и оно глючит. Думаю, все мы когда-то такое делали :-)

Но есть и другой случай. Когда программист попросту говоря крут, он попользовался тремя существующими библиотеками и увидел, что его конкретную задачу они не решают, и тогда ему надо либо перекроить задачу в более стандартную, либо написать свое решение. И если задача того стоит, то надо выбирать второй вариант. Ключевым отличием здесь является то, что программист должен быть крут, потому что иначе он со своей стоящей задачей все равно не справится :-). Об этом гораздо подробней писал Дж. Спольски, почитайте обязательно.

И Django, и TurboGears решают одну и ту же задачу: создание полного набора технологий ("full stack") для разработки веб-сайта: доступ к БД, контроллер веб-запросов, шаблоны. Только в Django все эти компоненты написаны самостоятельно, а TurboGears использует готовые: SQLObject, CherryPy и Kid соответственно. Так вот, в случае с Django я считаю, что написание с нуля было оправдано.

Переизобретение

Сразу сознаюсь, что с компонентами TurboGears я не знаком очень близко, поэтому могу и глупость какую сморозить :-). Но два из них: CherryPy и Kid — я когда-то смотрел, и они мне не понравились. Их действительно стоило переизобрести :-)

В CherryPy резко не понравилось то, что он сам жестко задает структуру URL. То есть да, он конечно полезен тем, что избавляет от написания логики вызова нужного кода по полученному веб-запросу, но как будет выглядеть URL он определяет сам. И сразу скажу, что определяет совсем не так, как мне бы понравилось: все параметры передаются через GET (или POST, видимо). В итоге URL'ы выглядят так:

http://server/?func=SomeFunc&id=3

Некрасиво :-(

Обработка же URL в Django — это сказка. Все построено на файле ("urlconf" на местном жаргоне), в котором соответствие URL'ов обрабатывающим функциям задается регулярками, и теми же регулярками вы можете выбрать из URL'ов значимые части и передать в качестве параметров в обрабатывающую функцию. Вид URL'ов можно задать какой угодно:

http://server/SomeFunc/3/
http://server/SomeFunc-3
http://server/subdomain-(3)/SomeFunc/

Плюс эти структуры URL'ов можно подключать друг к другу, и ваше приложение, включенное куда-то в структуру URL другого проекта, даже не заметит этого, потмоу что будет получать только известную ему часть URL. Добавьте к этому, что функция-обработчик получает еще и объект request, в котором удобно и единообразно собрана вся среда запроса: кукесы, GET, POST, сессия, авторизованный юзер и т.п...

Шаблоны Kid и вовсе страдают ограниченным применением: ими можно генерировать только well-formed XML, и именно гарантия well-formed'ности и является их основной фишкой. Проблема только в том, что шаблонами иногда нужно генерировать не только XML :-). А например CSS или просто текст или какой-нибудь код. Мало ли примененений бывает... Ну и кроме того, на мой вкус, впихивание шаблонной логики в параметры тегов просто плохо выглядит, и это тяжело править.

У шаблонной системы Django есть другая фишка: в ней намерено сильно ограничена логика для того, чтобы в шаблоны не утекала бизнес-логика приложения. Это утекание, к сожалению, часто становится проблемой многих шаблонных систем, которые позволяют фактически выполнять внутри себя питоновский код, что ведет к тому, что со временем уже никто сходу не знает, где начинать искать ошибку: на уровне контроллера или представления. В Django же написать в шаблоне какую-то нетривиальную логику сложнее вывода элементов списка в <li> просто нельзя.

Есть у TurboGears еще один компонент, которого пока нет в Django — Javascript'овая библиотека MochiKit. И вот тут как раз разработчики Django не стали изобртать ничего нового, а собираются интегрировать к себе тоже известную библиотечку — Dojo. Это показывает, что они не подвержены догмам ("все надо писать самому"), а выбирают решение, исходя из ситуации. (Тем, кто сейчас хочет в комментариях ткнуть меня носом вот сюда: то был юмор :-) .)

Интеграция

Еще одна сильная сторона Django по сравнению с TurboGears — интеграция всех компонентов. Они пишутся вместе, одной и той же командой, и поэтому хорошо работают вместе. Не могу сейчас конкретно ткнуть пальцем в пример, показывающий различия, но это может проявляться даже в таких мелочах, что переменная авторизованного юзера в запросе и шаблоне называется одинаково, или что все кодирование спецсимволов для URL'ов (%XX) делается только в каком-то одном месте, а не по всему фреймворку. И, например, документация для Django находится в одном месте и написана в одном стиле.

Другими словами, работать с умно интегрированной системой обычно гораздо приятней. А с тем, чтобы не допускать излишне тесной связанности компонентов, разработчики успешно справляются.

Короче говоря, даешь новые велосипеды! С углепластиковой рамой и GPS'ом под задницей :-)