Лучших работников в сфере IT РАБОТА-КА Вам поможет найти! о нас ✈
Я ищу работу в IT сфере ✈ Я ищу резюме в IT сфере ✈
Инженер схемотехник! 80000-100000 руб. ТК. соц.пак. Подробнее ✈

Обзор web-фреймворков на Питоне


В рамках этой статьи мы рассмотрим инструментарий, написанный на Питоне (и использующий его же), который делает работу веб-программиста легче и приятнее - веб-фреймворк. А точнее, даже несколько самых популярных питоновских
веб-фреймворков.
В процессе выбора веб-фреймворка для разработки сайта есть над чем задуматься. Если взять за критерий язык программирования, то для поклонников Microsoft и C# выбор очевиден - ASP.NET. Любителям Ruby тоже долго выбирать не приходится - Ruby On Rails. Сложнее Python, PHP и Java-программистам: количество веб-фреймворков для этих языков ужасает. Надеюсь, статья внесет некоторую ясность и поможет любителям Python'a сделать более осознанный выбор. Итак, плюсы питоновских веб-фреймворков:
Использование языка Python. Наверняка, восхваление Python'a уже порядком поднадоело, но на Python'e сайт действительно разрабатывается быстрее, приятнее и дешевле, чем на многих других языках.
Богатый выбор. Обилие фреймворков может испугать только новичка. Профессионала же всегда радует свобода выбора, поскольку шанс найти то, что действительно нужно, увеличивается. К тому же, выбор порождает конкуренцию, а здоровая конкуренция в свою очередь приводит к улучшению качества каждого фреймворка. Отсюда вытекает следующий плюс.
Бурное развитие. Постоянно появляются новые фреймворки, а их предшественники либо уступают дорогу молодым, либо продолжают борьбу за лидерство: фиксятся баги, вводятся новые фишки. Это отличает веб-сообщество Python'a от, например, веб-сообщества Ruby, которое в большинстве своем представлено фреймворком Ruby on Rails и в котором, в свою очередь, наблюдается некоторый застой из-за отсутствия новых идей.
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 и т.п. Эта тройка лидирует по популярности до сих пор.
WSGI
Как уже упоминалось, в Питоне существует большое количество веб-фреймворков, тулкитов и библиотек. Все они по-своему устанавливаются и настраиваются, и часто возникает проблема их взаимодействия между собой. По этой причине был разработан 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 - отличная документация и, пожалуй, самое крупное сообщество среди питоновских веб-фреймворков.
Чтобы загрузить первую пробную страницу сразу после установки, требуется всего три действия:
Создать новый проект командой django-admin.py startproject mysite.
Запустить локальный сервер: python manage.py runserver.
Запустить браузер и перейти по адресу http://127.0.0.1:8000 - откроется симпатичное окно с приветствием.
При знакомстве с Django в первую очередь подкупает его встроенный интерфейс администратора. В удобной форме он позволяет работать с контентом написанного сайта. Необходимо немного изменить настройки, и по адресу http://127.0.0.1:8000/admin в браузере можно запустить страницу, через которую легко можно управлять контентом (например, просматривать содержимое базы данных и изменять его).
Архитектура Django несколько отличается от классического MVC. Контроллер классической модели MVC примерно соответствует уровню, который в Django называется «Вид», а презентационная логика Вида реализуется уровнем Шаблонов. Из-за этого уровневую архитектуру Django часто называют «Модель-Шаблон-Вид» (MTV).
Для моделей Django предоставляет уровень абстракции, который избавляет от необходимости писать SQL-запросы для получения/сохранения данных в базу данных. Все таблицы, которые используются в приложении, пишутся в виде классов в отдельном файле models.py. Далее в коде, при помощи методов этих классов, происходит манипуляция содержимым таблиц. Таким образом, работа с базой данных становится полностью объектно-ориентированной. Django поддерживает работу с основными базами данных (PostgreSQL, SQLite3, MySQL, Oracle).
Также следует отметить весьма гибкий способ отображения urlов на функции приложения - при помощи регулярных выражений.
При разработке приложения удобно пользоваться встроенным сервером – он автоматически определяет изменения в файлах исходного кода проекта и перезапускается. Результат внесенных в код изменений сразу же отображается на веб-странице браузера, но использовать его в качестве «боевого» крайне не рекомендуется, так как он однопоточен и не предусматривает никаких мер безопасности. Для этих целей придется настраивать нормальный сервер (например, Apache). Отметим некоторые недостатки Django:
Язык шаблонов хоть и простой, но не очень «питоничен».
Не слишком удобная работа с AJAX;
Некоторым кажется, что в нем многовато «магии»;
Могут возникнуть трудности при замене компонентов (если ты не дружишь с регулярными выражениями, которые широко используются при отображении url’ов, то тебе может захотеться использовать другой диспетчер). Бытует мнение, что Django-разработчики частенько изобретают велосипеды (правда, Django дает возможность делать это легко и быстро).

Pylons
Pylons появился в сентябре 2005-го на основе Paste (набора утилит для разработки веба на Python'e; это своего рода фреймворк для фреймворков). Его создатель - Бен Бангерт. Среди всех фреймворков именно Pylons лучше всего отвечает WSGI-архитектуре, причем он был задуман таким с самого начала. В мире фреймворков он является своего родом антиподом Django. Все его компоненты образуют middleware-стек (о котором упоминалось чуть выше при описании WSGI). Программист может заменить любой из составляющих этого стека на другой middleware. Такой подход делает Pylons потрясающе гибким! Между прочим, нечто сходное можно увидеть у Unix-систем. Те следуют принципу: лучше иметь много ускоспециализированных утилит, каждую из которых можно заменить на что-то более подходящее, чем одну большую, которая умеет все. Очень сильное влияние на него оказал набиравший тогда популярность Ruby On Rails – такие важные компоненты как Routes и WebHelpers взяты именно из RoR.
Pylons содержит следующие компоненты: Paste как веб-сервер, SQLAlchemy для ORM, Mako (или Myghty) для шаблонов, Routes как диспетчер url-запросов. Полезными функциями обладает WebHelpers (например, работа с AJAX, создание RSS). Еще раз подчеркну, что любой из этих компонентов можно заменить по своему вкусу. Таким образом, Pylons закрывает практически все вышеупомянутые недостатки Django: гибкость в выборе компонентов, удобная работа с AJAX. К тому же, имевшие ранее дело с Ruby On Rails сразу почувствуют себя в своей тарелке. Тем не менее, Pylons не лишен недостатков. Как ни странно, они вытекают из его достоинств:
Pylons не занимается документацией, поддержкой и улучшением компонентов, которые в нем можно использовать - эта ответственность лежит на производителях компонент. В результате, если, к примеру, ты наталкиваешься на баг при использовании SQLObject, то трудно понять, кто виноват: Pylons или SQLObject. Отсюда также следует, что чаще всего документацию придется искать не по Pylons, а по какому-то отдельному компоненту. И не всегда он бывает документирован надлежащим образом.
Отметим меньший размер комьюнити по сравнению с Django или TurboGears. Но не стоит из этого делать поспешных выводов о качестве. Например, есть возможность без проблем установить контакт непосредственно с лидерами проекта. Кроме того, баги фиксятся быстро и эффективно (что не всегда можно сказать о том же Django).
Haas, Кристоф Пилоны начала . Проверено 5 июля 2007
Genshi Wiki пилоны с Genshi Проверено 5 июля 2007
Пилоны Проект FAQ.
Заметки на пилонах и repoze.bfg слияния. URL: http://be.groovie.org/post/1558848023/notes-on-the-pylons-repoze-bfg-merger
TurboGears
Так же, как и Django, TurboGears был разработан для быстрого создания новостных сайтов. Но его автор, Кевин Дангор, пошел по другому пути. Дело в том, что когда Django создавался (2000), еще не существовало необходимых компонент (например, SQL ORM), поэтому разработчикам пришлось создавать свои собственные решения. TurboGears же разрабатывался позже, поэтому перед Кевином был довольно богатый выбор уже готовых компонент. Кевин выбрал из них лучшие и разработал новый фреймворк - TurboGears. Были выбраны:
CherryPy для диспетчеризации url, как http-сервер и система конфигурации;
Kid для шаблонов;
SQLObject для базы данных;
MochiKit для Javascript.
Поскольку тогда не было подходящих компонентов для интерфейса администратора, авторизации пользователей, работы с формами, то они были разработаны с нуля.
Однако такой подход поставил TurboGears в зависимое положение от развития выбранных сторонних компонент, что и привело к неприятным последствиям. Поддержка Kid прекратилась, и ему на смену пришел Genshi. SQLAlchemy начал вытеснять SQLObject. Были обнаружены недостатки в библиотеках Javascript. К тому же, некоторые пользователи требовали WSGI, Routes и Cheetah. Пришлось принимать меры: проблему с шаблонами решили, разработав новый шаблонный движок Buffet, были написаны HOWTOs для SQLAlchemy; CherryPy 3 начал поддерживать WSGI и Routes.
Разработчики пришли к мысли, что понятие «лучший компонент» субъективно и непостоянно. Фокус был смещен в сторону гибкости, которой изначально TurboGears (как и Django) был обделен. Именно поэтому в 2007 году свет увидел TurboGears2, который был построен на основе Pylons. Конечно, это не значило, что TurboGears слился с Pylons, хотя событие и сблизило комьюнити обоих фреймворков.
TurboGears по-прежнему держит курс на использование сторонних, дружественных к пользователю компонент, Pylons же концентрирует усилия на компонентах, составляющих его «ядро». Оба стараются использовать общие компоненты для общих нужд (например, хотя Pylons и использует по умолчанию для шаблонов Mako, он также поддерживает использование Genshi, который характерен для TurboGears). На данный момент поддерживаются обе ветки: 1.х и 2.х, но рекомендуется по возможности переходить на 2.x.
Недостатки:
Недальновидная ставка на «лучшие» на данный момент компоненты (со временем ситуация может измениться);
Неполная совместимость 1.x и 2.x версий;
По сравнению с Django: не такая полная документация (местами содержит рецепты и примеры, а не справочники); менее прозрачная схема urlов.
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. В действительности, каждый фреймворк имеет свои удобства (иначе он бы не приобрел известность). Фреймворк - это всего лишь инструмент, и то, какой будет выбран, в первую очередь должно зависеть от поставленной задачи, и только потом от его популярности.
INFO
Один из создателей Django - профессиональный журналист, и это лучшим образом сказалось на качестве документации!
Сразу после выхода TurboGears приобрел огромную популярность: за первые 3 месяца было скачано более 30000 скринкастов.
В Zope Corporation (фирме-создательнице Zope) с 2000 по 2003 год работал сам Гвидо ван Россум (автор Python'a).
WWW
http://djbook.ru - русский перевод книги по Django (правда, местами еще не полный).
http://pyobject.ru/blog/2007/01/31/concepts-of-pylons - описание Pylons, сравнение с Django и TurboGears.
http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks - сравнение веб-фреймворков (не только Питоновских).
Вадим Шпаковский
Блог Работа КА Каталог Резюме Каталог Вакансии Горячие вакансии Freelance удаленная работа IT FreeSoft бесплатный софт Python news IT Новинки Фото нравится
Rambler's Top100 HotLog Яндекс.Метрика
Отправить комментарий