В рамках этой статьи мы рассмотрим инструментарий, написанный на Питоне (и использующий его же), который делает работу веб-программиста легче и приятнее — веб-фреймворк. А точнее, даже несколько самых популярных питоновских веб-фреймворков.
ПИТОНОВСКИЕ ВЕБ-ФРЕЙМВОРКИ
В процессе выбора веб-фреймворка для разработки сайта есть над чем задуматься. Если взять за критерий язык программирования, то для поклонников Microsoft и С# выбор очевиден —ASP.NET. Любителям Ruby тоже долго выбирать не приходится — Ruby On Rails. Сложнее Python, PHP и Java-программистам: количество веб-фреймворков для этих языков ужасает. Надеюсь, статья внесет некоторую ясность и поможет любителям Python’a сделать более осознанный выбор. Итак, плюсы питоновских веб-фреймворков:
1) Использование языка Python. Наверняка, восхваление Python’a уже порядком поднадоело, но на Python’e сайт действительно разрабатывается быстрее, приятнее и дешевле, чем на многих других языках.
2) Богатый выбор. Обилие фреймворков может испугать только новичка. Профессионала же всегда радует свобода выбора, поскольку шанс найти то, что действительно нужно, увеличивается. К тому же, выбор порождает конкуренцию, а здоровая конкуренция в свою очередь приводит к улучшению качества каждого фреймворка. Отсюда вытекает следующий плюс.
3) Бурное развитие. Постоянно появляются новые фреймворки, а их предшественники либо уступают дорогу молодым, либо продолжают борьбу за лидерство: фиксятся баги, вводятся новые фишки. Это отличает веб-сообщество Python’a от, например, веб-сообщества Ruby которое в большинстве своем представлено фреймворком Ruby on Rails и в котором, в свою очередь, наблюдается некоторый застой из-за отсутствия новых идей.
4) Opensource. Наверное, с нашим с тобой флибустьерским менталитетом, это не ахти какой плюс. Но, говорят, легально и бесплатно пользоваться качественным софтом — это здорово.
На данный момент насчитывается несколько десятков питоновских веб-фреймворков. Далее будут подробно рассмотрены три самых крупных и известных: Django, Pylons и TurboGears. Также будут упомянуты несколько других интересных фреймворков: Zope, Twisted, CherryPy.
КАК ВСЕ НАЧИНАЛОСЬ
World Wide Web появилась в 1990 году. В 1996 свет увидел Grail — веб-браузер, написанный на Питоне. Он существовал всего лишь до 1999 года, но дал толчок к дальнейшему развитию питоновских веб-библиотек. В 1998 году появился Zope — настоящий солидный фреймворк, своего рода Emacs для веб-приложений. Но некоторые ставили ему в упрек монолитность и громоздкость (фактически, он вводил новый язык программирования]. Поэтому начали разрабатываться такие фреймворки как Webware (2000), Quixote (2000, по сути — упрощенный Zope), Twisted (весьма своеобразный асинхронный фреймворк), CherryPy и др. Количество фреймворков росло, как грибы после дождя, что обусловило появление стандарта WSGI (о нем чуть позже). Следующей вехой в истории питоновских фреймворков стал 2005 год. Именно тогда появились Django, Pylons и TurboGears — представители новой эры «мегафреймворков». Они совместили традиционные веб-сервисы, которые предоставлялись и раньше, с такими аддонами как шаблонные «движки», SQL ORM, библиотеками Javascript и т.п. Эта тройка лидирует по популярности до сих пор.
W5GI
Как уже упоминалось, в Питоне существует большое количество веб-фреймворков, тул китов и библиотек. Все они по-своему устанавливаются и настраиваются, и часто возникает проблема их взаимодействия между собой. По этой причине был разработан WSGI (Web Server Gateway Interface) — стандарт взаимодействия между Python-программой, выполняющейся на стороне сервера, и самим веб-сервером. Все современные питоновские веб-фреймворки ему соответствуют. Втом числе, WSGI определяет middleware-компоненты, которые предоставляют интерфейсы как приложению, так и серверу. То есть, для сервера middleware является приложением, а для приложения — сервером. Это позволяет составлять цепочки WSGI-совместимых middlewares. Таким образом (в теории), подбирая нужные middleware-компоненты, можно составлять собственные фреймворки! Эта концепция наиболее широко проявила себя в Pylons (о чем будет рассказано далее).
MVC
Архитектура многих фреймворков сходна между собой и соответствует паттерну MVC (Model-View-Controller). Согласно этому паттерну, приложение разбивается натри части:
• Модели — содержат данные, с которыми работает приложение. Часто соотносится с таблицами базы данных.
• Виды — отвечают за чтение данных из модели и их отображение пользователю.
• Контроллер — логика приложения. Он вызывает виды для отображения данных пользователю, либо получает данные от пользователя и сохраняет их в моделях. ( Идея MVC в изоляции, так что можно менять одну часть, не ломая другие.
DJANGO
Самый популярный на данный момент из своих собратьев. Был разработан специально для быстрого и удобного написания новостных сайтов компании The World Company ее сотрудниками Эдрианом Холовати и Симоном Виллисоном. Начал разрабатываться еще с 2000 года, но широкой общественности был представлен лишь в середине 2005-го. Свое название получил в честь джазового гитариста Джанго Рейнхардта (а я думал, что в честь того Джанго из одноименного вестерна, который таскал с собой пулемет в гробу на веревочке.
— Прим. ред.).
Сайт на Django строится из одного или нескольких приложений, которые рекомендуется делать отчуждаемыми и подключаемыми (в отличие, например, от Ruby on Rails). Одно из самых больших преимуществ Django, отличная документация и, пожалуй, самое крупное сообщество среди питоновских веб-фреймворков.
Чтобы загрузить первую пробную страницу сразу после установки, требуется всего три действия:
1) Создать новый проект командой django-admin.py startproject mysite.
2) Запустить локальный сервер: python manage.ру runserver.
3) Запустить браузер и перейти по адресу httр://127.0.0.1:8000 — откроется симпатичное окно с приветствием.
При знакомстве с Django в первую очередь подкупает его встроенный интерфейс администратора. В удобной форме он позволяет работать с контентом написанного сайта. Необходимо немного изменить настройки, и по адресу http://127.0.0.1:8000/admin в браузере можно запустить страницу, через которую можно управлять контентом (например, просматривать содержимое базы данных и изменять его). Архитектура Django несколько отличается от классического MVC. Контроллер классической модели MVC примерно соответствует уровню, который в Django называется «Вид», а презентационная логика Вида реализуется уровнем Шаблонов. Из-за этого уровневую архитектуру Django часто называют«Модель-Шаблон-Вид» (MTV). Для моделей Django предоставляет уровень абстракции, который избавляет от необходимости писать SQL-запросы для получения/сохранения данных в базу данных. Все таблицы, которые используются в приложении, пишутся в виде классов в отдельном файле models.ру. Далее в коде, при помощи методов этих классов, происходит манипуляция содержимым таблиц. Таким образом, работа с базой данных становится полностью объектно-ориентированной. Django поддерживает работу с основными базами данных (PostgreSQL, SQLite3, MySQL, Oracle). Также отметим весьма гибкий способ отображения иг1ов на функции приложения — при помощи регулярных выражений. При разработке приложения удобно пользоваться встроенным сервером—он автоматически определяет изменения в файлах исходного кода проекта и перезапускается. Результат внесенных в код изменений сразу же отображается на веб-странице браузера, но использовать его в качестве «боевого» крайне не рекомендуется, так как однопоточен и не предусматривает никаких мер безопасности. Для этих целей придется настраивать нормальный сервер (например, Apache). Назовем некоторые недостатки Django:
• Язык шаблонов хоть и простой, но не очень «питоничен».
• Не слишком удобная работа с AJAX;
• Некоторым кажется, что в нем многовато «магии»;
• Могут возникнуть трудности при замене компонентов (если ты не дружишь с регулярными выражениями, которые широко используются при отображении, то тебе может захотеться использовать другой диспетчер). Бытует мнение, что Django-разработчики частенько изобретают велосипеды (правда, Django дает возможность делать это легко и быстро).
PYLONS
Pylons появился в сентябре 2005-го на основе Paste (набора утилит для разработки веба на Python’e; это своего рода фреймворк для фреймворков). Его создатель — Бен Бангерт. Среди всех фреймворков именно Pylons лучше всего отвечает архитектуре, причем он был задуман таким с самого начала. В мире фреймворков он является своего родом антиподом Django. Все его компоненты образуют middleware-стек (о котором упоминалось чуть выше при описании WSGI). Программист может заменить любую из составляющих этого стека на другой middleware. Такой подход делает Pylons потрясающе гибким! Между прочим, нечто сходное можно увидеть у Unix-систем. Те следуют принципу: лучше много узкоспециализированных утилит, каждую из которых можно заменить на что-то более подходящее, чем одна большая, которая умеет все. Очень сильное влияние на него оказал набиравший тогда популярность Ruby On Rails — такие важные компоненты как Routes и WebHelpers взяты именно из RoR.
Pylons содержит следующие компоненты: Paste как веб-сервер, SQLAlchemyдля ORM, Мако (или Myghty) для шаблонов, Routes как диспетчер url-запросов. Полезными функциями oблaдaeт WebHelpers (например, работа с AJAX, создание RSS). Еще раз подчеркну, что любой из этих компонентов можно заменить по вкусу. Таким образом, Pylons закрывает практически все вышеупомянутые недостатки Django: гибкость в выборе компонентов, удобная работа с AJAX. К тому же, имевшие ранее дело с Ruby On Rails сразу почувствуют себя в своей тарелке. Тем не менее, Pylons не лишен недостатков. Как ни странно, они вытекают из его достоинств:
• Pylons не занимается документацией, поддержкой и улучшением компонентов, которые в нем можно использовать — эта ответственность лежит на производителях компонент. В результате, если, к примеру, ты наталкиваешься на баг при использовании SQLObject, то трудно понять, кто виноват: Pylons или SQLObject. Отсюда также следует, что чаще всего документацию придется искать не по Pylons, а по какому-то отдельному компоненту. И не всегда он бывает документирован надлежащим образом.
• Отметим меньший размер комьюнити по сравнению с Django или TurboGears. Но не стоит из этого делать поспешных выводов о качестве. Например, есть возможность без проблем установить контакт непосредственно с лидерами проекта. Кроме того, баги фиксятся быстро и эффективно что не всегда можно сказать о том же Django).
TURBOGEARS
Так же, как и Django, TurboGears был разработан для быстрого создания новостных сайтов. Но его автор, Кевин Дангор, пошел по другому пути. Дело в том, что когда Django создавался (2000), еще не существовало необходимых компонент (например, SQL0RM), поэтому разработчикам пришлось создавать собственные решения. TurboGears же разрабатывался позже, поэтому перед Кевином был довольно богатый выбор уже готовых компонент. Кевин выбрал лучшие и разработал новый фреймворк — TurboGears. Были выбраны: СЬеггуРудля диспетчеризации url как http-сервер и система конфигурации; Kid для шаблонов; SQLObject для базы данных; MochiKit для Javascript. Поскольку тогда не было подходящих компонент для интерфейса администратора, авторизации пользователей, работы с формами, то они были разработаны с нуля. Однако такой подход поставил TurboGears в зависимое положение от развития выбранных сторонних компонент, что и привело к неприятным последствиям. Поддержка Kid прекратилась, и ему на смену пришел Genshi. SQLAlchemy начал вытеснять SQLObject. Были обнаружены недостатки в библиотеках Javascript. К тому же, некоторые пользователи требовали WSGI, Routes и Cheetah. Пришлось принимать меры: проблему с шаблонами решили, разработав новый шаблонный движок Buffet, были написаны HOWTOs для SQLAlchemy; CherryPy3 начал поддерживать WSGI и Routes.
Разработчики пришли к мысли, что понятие «лучший компонент» субъективно и непостоянно. Фокус был смещен в сторону гибкости, которой изначально TurboGears (как и Django) был обделен. Именно поэтому в 2007 году свет увидел TurboGears2, который был построен на основе Pylons. Конечно, это не значило, что TurboGears слился с Pylons, хотя событие и сблизило комьюнити обоих фреймворков. TurboGears по-прежнему держит курс на использование сторонних, дружественных к пользователю компонент, концентрирует усилия на компонентах, составляющих его «ядро». Оба стараются использовать общие компоненты для общих нужд (например, хотя Pylons и использует по умолчанию для шаблонов Мако, он также поддерживает использование Genshi, который характерен для TurboGears).
Недостатки:
• Недальновидная ставка на «лучшие сегодня» компоненты (со временем ситуация может измениться);
• Неполная совместимость 1 .х и 2.x версий;
• По сравнению с Django: не такая полная документация (местами содержит рецепты и примеры, а не справочники); менее прозрачная схема urloв.
ZOPE
Как уже упоминалось, Zope был первым из полноценных питоновских веб-фреймворков, и его архитектура достаточно сильно отличается от архитектуры собратьев. Особенностью Zope является объектно-ориентированность: все данные представляются в виде компонентов, занимающих определенное место в общей иерархии и хранящихся во встроенной объектной базе данных(ZoBD). По сути, программирование в Zope сводится к проектированию иерархии компонентов. Многие фишки Zope стали следствием такого подхода. Например, механизм acquisition — нечто похожее на наследование в ООП: каждый объект наследует поведение и свойства объектов, в иерархии которых находится (родителей). По правде говоря, такое поведение может послужить источником сюрпризов, поэтому в Zope3 использование механизма сделали явным. Многие ставили Zope в упрек монолитность и громоздкость, поэтому в конце 2004. года общественность увидела Zope3. Главным отличием стала модульность фреймворка, что придало ему еще большую гибкость. Причем, он не поддерживал обратной совместимости с Zope2, что обусловило внедрение парадигм Zope3 в прежнюю Zope2. Таким образом, сейчас развиваются обе ветки. С 2007 года появилась возможность устанавливать модули, пользуясь питоновской egg-технологией. На данный момент это единственный способ обновлять Zope3 (последнее обновление «одним куском» 3.4 было в начале 2009 года и больше не предвидится). Zope — активно развивающийся стабильный продукт. В 2006 появился Grok — новый веб-фреймворк, расширяющий идеи Zope3.
TWISTED
Основывается на парадигме событийно-ориентированного программирования: следуя ей, пользователь пишет короткие функции обратного вызова, которые затем вызываются фреймворком. Центральной является концепция отложенных вычислений. Вычисление некоторого выражения может оказаться невозможным (например, для этого требуются данные от удаленного клиента). Такие выражения могут существовать в виде объектов, но их значение не может быть запрошено. С каждым выражением связана цепочка функций обратного вызова. Когда необходимые данные становятся доступными, результат вычисления выражения передается по этой цепочке. Работа с потоками организована по тому же механизму.
CHERRYPY
Одной из целей создателя языка — Реми Делона — было сотворение библиотеки, которая бы максимально соответствовала питон о веко му стилю (как раз то, чего порой не хватает Django или Zope). Это позволило разработчикам использовать фреймворк как любой обычный модуль Python и не думать об особенностях веб-программирования.
CherryPy представляет собой надстройку над http-протоколом, но остается на низком уровне. Он может выступать в качестве самостоятельного веб-сервера или работать под управлением другого серверного приложения, поддерживающего протокол WSGI. Он не занимается такими задачами, как обработка шаблонов для вывода данных, доступ к базе данных и авторизация пользователя. Фреймворк расширяется за счет фильтров, простых интерфейсов, состоящих из функций, которые вызываются в определенных точках процесса обработки запросов/ответов.
Как уже упоминалось, CherryPy был выбран в качестве компонента TurboGears для диспетчеризации url как http-сервер и система конфигурации, что говорит о том, что в то время он был лучшим.
ЗАКЛЮЧЕНИЕ
Из множества питоновских веб-фреймворков пока можно выделить трех фаворитов: Django, Pylons и TurboGears. И если с последним у некоторых могут возникнуть сомнения, то Django и Pylons можно смело рекомендовать для разработки сайта. Если тебя привлекает гибкость и модульность — значит, выбор падает на Pylons. Если устраивает целостный, хорошо настроенный и документированный набор компонент — используй Django.
В действительности, каждый фреймворк имеет свои удобства
иначе он бы не приобрел известность). Фреймворк — это всего лишь инструмент, и то, какой будет выбран, в первую очередь должно зависеть от поставленной задачи, и только потом от его популярности.