Концепции Pylons

Не бесспорная статья Кристофа Хааса. Тем не менее, достаточно интересна. Мне приглянулась описанием Django, TurboGears и Pylons. По крайней мере, у меня схожие ощущения от Django и Pylons.

Обсуждение статьи (на английском) можете посмотреть в группе pylons-discuss

Перед прочтением советую ознакомиться с кратким обзором Pylons.

Далее - перевод.

Добро пожаловать в Pylons (Пилоны). Скорее всего вы здесь, потому что желаете написать веб приложение и ищите способ сделать это проще. Возможно, вы раньше писали CGI скрипты, или использовали PHP. Что ж, Pylons — это веб фреймворк, который возможно работает несколько иначе, чем вы привыкли. Если вы использовали другие фреймворки: Django, TurboGears или Ruby on Rails, то вы понимаете о чем я. Это введение поможет понять вам для чего Pylons нужны и как выглядит разработка с использованием Pylons.

Что такое фреймворк

Как сказано выше, Pylons — это веб фреймворк. Вообще говоря, фреймворк — это набор компонент (таких как другие программы, библиотеки или даже скриптовые языки), которые работают вместе для формирования базовой основы вашего приложения. Когда вы пишите веб приложение, вам зачастую нужны некоторые общие инструменты:

  • нечто, что генерирует HTML;
  • нечто, что разбирает аргументы, переданные по HTTP;
  • нечто общающееся с базой данных;
  • нечто содержащее логику вашего приложения;
  • нечто управляющее пользовательскими аккаунтами;
  • нечто сохраняющее промежуточные данные (напр. сессии, основанные на куках).

Если вы писали веб приложение (даже если это был простейший скрипт, выводящий “Hello, World!”), то значит вы писали бОльшую часть вещей, описанных выше, самостоятельно. Вы, возможно, просто использовали print для создания HTML и не заботились о сложных системах шаблонов. Это хорошо работает с простыми приложениями, но программы имеют тенденцию расти, и без хороших концепций, они становятся проблемными в обслуживании и поддержке. Иными словами, через некоторое время у вас будет куча программ, которые выводят HTML подобным образом. Уверен, вы можете перенести некоторые общие части в модули и использовать их из всех ваших программ. Но в действительности, вы ищите решения для сверхтипичных задач, возникающих в каждом веб приложении.

Так что некоторые продвинутые люди потратили свое свободное время для создания компонент, которые “закрывают” эти ежедневные задачи. Например, существует Python пакет Mako, который работает с созданием HTML — т.е. является системой шаблонов. Используя Mako, вы создаете файл (называемый шаблоном), который содержит целиком вашу HTML страницу. Но у вас есть возможность добавить Python конструкции прямо в этом файле, в том месте, где вам нужно, а также получить доступ к переменным из других частей вашего приложения. И поскольку эти шаблоны могут использовать друг-друга, то вы имеете возможность легко поменять дизайн вашего сайта, просто изменив базовый шаблон.

Это просто пример того, как компоненты могут облегчить жизнь программисту. И существует большое количество уже готовых компонент. Это очень хорошая идея — использовать их, вместо того чтобы вручную разбирать каждодневную рутину. А теперь представьте, что у вас несколько полезных компонент и они работают слаженно, вместе. Так вот, веб фреймворки, такие как Pylons, как раз и занимаются этим.

Что такое MVC?

Возможно вы уже сталкивались с аббревиатурой MVC в контексте веб фреймворков. MVC — сокращение от Model-View-Controller (модель, вид/представление, контроллер). Это один из подходов, используемых при разработке ПО. При помощи данного подхода, приложение разбивается на:

Модели — содержат данные, с которыми работает ваше приложение. Модели не содержат информации о значении этих данных. Часто модель соотносится с таблицами базы данных.

Виды — отвечают за чтение данных из модели и их отображение пользователю. (В то время как модели и контроллеры имеют точно такие же названия в Pylons, следует отметить что в Pylons виду соответствует шаблон).

Контроллер — здесь находится логика приложения. Контроллер вызывает виды для отображения данных пользователю, либо получает данные от пользователя и сохраняет их в моделях.

Возможно вы уже писали программы, которые “общаются” с базой данных, выводят HTML и содержат некоторую логику. Идея MVC в изоляции, так что вы можете менять одну часть не ломая другие.

(Для более подробного описания см. статью из Википедии )

Компоненты Pylons

Поскольку Pylons состоят из нескольких компонент, то новичку будет непросто понять, как эти компоненты взаимодействуют. Попробую объяснить. Все начинается с Paste.

Paste

Paste — веб сервер и инструмент, помогающий в развертывании вашего приложения. Как видно из paste script, ваш конфигурационный файл development.ini состоит из двух разделов:

  • [server:main] — этот раздел нужен для самого Paste. В нем описывается, какой IP адрес и какой TCP порт использовать Paste для своего веб сервера. Строка use= ссылается на egg (автоматический способ установки Python пакетов) с Paste.
  • [app:main] — этот раздел описывает настройки вашего приложения.

В документации к Pylons говорится, что веб сервер с вашим приложением запускается командой paster serve --reload development.ini. Если вы не указываете имя приложения (app:name) в опциях, Paste будет искать приложение main. Вот таким образом он берет [app:main]. После некоторых внутренних операций, Paste загружает ваш config/middleware.py и оттуда запускает make_app. Вы можете изменить эту функцию согласно вашим требованиям.

Очень много подробностей вы можете увидеть в Pylons execution analysis.

SQLAlchemy

Большинство веб приложений используют базы данных в качестве хранилища. Вы можете сохранять данные ваших клиентов, статьи, описания для e-shop, в общем, все что угодно. У SQLAlchemy есть пара полезных возможностей:

  • SQL тулкит
  • ORM (object relational mapper)

SQL тулкит” легко объяснить: вы определяете таблицы в базе данных и больше вообще не пишите SQL-запросов. Можно воспринимать SQLAlchemy, как некоторый уровень абстракции. Если вы в приложении используете эту абстракцию, то вы можете поменять СУБД, скажем, с MySQL на PostgreSQL и не беспокоиться о разницах между этими СУБД.

Гораздо более интересно то, что касается ORM. Вообразите, что вы определяете таблицы базы данных в синтаксисе Python, создавая Python класс. Теперь вы вызываете специальную функцию ,которая магическим образом “склеивает” класс с таблицей. Например:

Customer.select_by(name='Kennedy')

Этот пример выполнит запрос к БД и “вытащит” запись из таблицы, отвечающая вашим клиентам, в которой имя — Kennedy. Ведь это гораздо приятней, чем писать SQL запросы?

Полную документацию можно найти на сайте SQLAlchemy.

К слову говоря, SQLObject — еще один известный SQL тулкит. Ходят слухи, что SQLObject проще и что SQLAlchemy не готов к промышленному использованию (production ready). В действительности, похоже что мало-помалу SQLAlchemy набирает популярность. SQLObject имеет некоторые ограничения (как например, основной ключ должен быть типа integer, хотя это не всегда так). SQLObject несколько менее точен, а его синтаксис странноват.

Mygthy

Это шаблонный движок. Вместо того чтобы вставлять print в код, вы используете шаблоны, который выводят HTML пользователю. Файл шаблона содержит только HTML. И если у вас есть статическая страница, вы просто говорите программе:

render_response('welcome.myt')

и Mygthy загрузит файл templates/welcome.myt и покажет пользователю.

Это немного скучно. Становится интересно, когда нужно добавить некий Python код в шаблон. Простой пример:

<html><body>    <h1>Welcome</h1>    <p>Today we serve:</p>    <ul>% for meal in ['calzone', 'porkpie', 'pizza']:        <li><% meal %></li>% # end of for loop    </ul></body></html>

Шаблоны поддерживают некоторые потрясающие вещи. Вы можете использовать переменные, которые определяются в вашем приложении. Вы можете включать другие шаблоны, или наследоваться от них. Подробности см. на сайте Myghty.

Если вы использовали PHP в таком ключе для вывода HTML вместе с программной логикой, то вам будет это привычно.

Routes

Интересные особенности веб фреймворков в том, что вы контролируете абсолютно все с данными, получаемыми от пользователя. Это включает и управление URLами. Routes позволяет выбирать действие в зависимости от URLа. Например, возьмем такой URL:

http://pylonshq.com/blog/2007/01

Вы можете сказать Routes, чтобы обрабатывал это запрос контроллерblog, получая ‘2007’ как параметр year и ‘01’ как параметр month. В синтаксисе Routes это будет выглядеть так:

m.connect('blog/:year/:month', controller='blog')

Настройка роутинга URLов находится в config/routing.py вашего приложения.

WebHelpers

Даже с использованием вышеописанных компонент, вы будете ловить себя на том, что вновь пишете функции для выполнения каждодневной работы. Пакет WebHelpers содержит такие функции, и вы их можете использовать в Pylons-приложении. Некоторые примеры, что могут WebHelpers:

  • просто и элегантно управлять элементами AJAX
  • форматировать текст и числа
  • создавать URLы, ссылки, элменты HTML форм
  • создавать RSS-фиды

Также в WebHelpers содержатся функции, портированные с фреймворка Ruby on Rails. WebHelpers не только помогают сократить время на решении каждодневных скучных задач, но также имеет поддержку скриптов с JavaScript-библиотеки , которая может быть использована для AJAX или прикольных графических эффектов с целью впечатлить коллег. Чтобы примерно понять как это выглядит — пройдитесь по .

Существуют ли другие веб фреймворки?

Да. Два других, наиболее часто упоминаемых фреймворков, — Django и TurboGears. Нигде нет более-менее честного их сравнения, поскольку все три фреймворка пытаются реализовать (не)cхожую функциональность. И разные программисты могут ожидать разного от инструментов. Но в любом случае, я попытаюсь сравнить.

Django ориентирован на программистов, часто работающих с контентом. Создатели Django — из газетного бизнеса. Они говорят, что их часто просят реализовать некоторые “фишки” на сайте в очень краткое время. Так что они написали свой собственный фреймворк. Django не использует уже готовые компоненты. Даже для доступа к БД (то, что называется ORM) они используют собственное решение. Если у вас требования аналогичны запросам авторов Django, то этот веб фреймворк создан для вас. Но это совсем не значит, что легко будет заменить компонент, который вам не сильно нравится, на нечто другое. Их язык шаблонов не очень “питоничен” (pythonic) — это собственный язык, хотя и очень простой. Весьма приятная возможность фреймворка — автоматический административный интерфейс — при помощи него легко управлять изменять ваши данные. Вдобавок, в этом фреймворке достаточно остроумный способ отображения URLов на функции вашего приложения — при помощи регулярных выражений. AJAX возможен с Django, но не слишком удобен. Далее, в фреймворке есть встроенный веб сервер, но рекомендуется использовать Apache c mod_python. Одну вещь можно с уверенностью сказать о Django: у них хороший маркетинг :-) Django хорошо документирован, имеет крупное сообщество и, вдобавок, сейчас пишется книга. В целом, Django — фреймворк “don’t worry — be happy”, с тесно интегрированными компонентами. Он поможет вам делать свою работу быстрее, если вы не слишком заботитесь о выборе используемых компонент и не ожидаете, что все части будут выглядеть “питонично” (pythonic). И еще — в нем многовато ”магии”.

TurboGears создан на базе существующих компонент. Веб сервер работает на CherryPy, HTML шаблоны — на Kid, он получает доступ к БД при помощи SQLObject и вдобавок включает в себя MochiKit — JavaScript библиотеку для создания AJAX-приложений. В нем проще чем в Django заменить некоторые компоненты, если они вам не сильно нравятся. Например, вы можете “выбросить” SQLObject и использовать SQLAlchemy вместо него; хотя большинство частей TurboGears не могут похвастаться хорошей поддержкой SQLAlchemy. Схема отображения URLов в TurboGears менее прозрачна. Вы не можете явно сказать, что именно нужно делать с конкретным URLом. Вместо этого вы создаете контроллер с таким же именем, как и первая часть URLа. Так что URLы, которые видит пользователь, менее изящны. Удобная “фишка” TurboGears — это набор веб утилит. Среди них — WidgetBrowser для обзора библиотеки элементов форм, или Catwalk — фронтенд для администрирования БД, подобный автоматической админки Django. TurboGears хорошо документирован и также имеет крупное сообщество. В целом, у TurboGears есть удобные “фишки”, такие как библиотека виджетов или набор качественных инструментов, которые делают жизнь чуть проще. Их документация в некоторых местах не полна и содержит рецепты и примеры, а не справочники. Переход на SQLAlchemy анонсирован публично, но много вещей все еще работают только с SQLObject. TuboGears может быть хорошим выбором для программистов, которых пугает “магия” Django и которым нравятся бОльшая прозрачность.

Pylons не новичок, но сообщество у них гораздо меньше чем у Django или TurboGears. Это не означает, что Pylons технически хуже остальных. Уникальность этого фреймворка в минимализме и бОльшей гибкости по сравнению с другими. Вообще говоря, чтобы начать использовать Pylons, достаточно изучить базовые понятия компонент. Далее, нужно понять как эти компоненты управляются из Pylons-приложения. Так что Pylons — это клей между компонентами, с добавлением мощного пакета WebHelpers. Гибкость Pylons означает что вы можете менять компоненты очень легко. Вам не нравится SQLAlchemy? Используйте SQLObject! Вам кажется Myghty избыточным по сравнению с Mako? Используйте Mako! Pylons не связывают по рукам и ногам, но стараются помочь с использованием компонент, отличных от стандартных. Компоненты осмотрительно выбираются из кандидатур, оглядываясь на ошибки других веб фреймворков. Документация к Pylons далека от идеала, и пока еще нет “Pylons Handbook”. Некоторые говорят, что Pylons это Ruby on Rails, написанные на Python.

Чем использование веб фреймворка отличается от программирования CGI?

Много программистов пишут CGI используя скриптовый язык, например как Perl. В первую очередь, в силу поддержки со стороны хостинга. CGI — это программа, которая запускается веб сервером при запросе пользователя конкретного URLа. CGI получает информацию, посылаемую веб браузером (и из некоторых переменных окружения веб сервера) и выводит HTML, отображаемый в браузере. Так что вам как минимум нужен веб сервер, например Apache.

С веб фреймворком, таким как Pylons, вам не обязательно использовать отдельный веб сервер. Pylons включают в себя веб сервер Paste. Этот подход имеет некоторые преимущества:

  • вы легко можете разрабатывать приложение на рабочей станции, поскольку вам не требуется дополнительное ПО в виде стороннего веб сервера, например Apache
  • вы практически полностью контролируете поведение веб сервера (например, коды HTTP ошибок)
  • вы можете использовать гибкие схемы URLов. В CGI URLы всегда отражают имя CGI-скрипта. С Pylons вы можете определять действия на URL по шаблону
  • веб сервер держит ваше приложение в памяти, целиком. Когда вы используете CGI, веб сервер при каждом запросе заново запускает интерпретатор вашего скрипта, так что есть издержки, особенно ощутимые на загруженных веб серверах.

Как лучше всего начать работать с Pylons?

Поскольку Pylons — это компоненты, собранные и склеенные воедино, так что нет особого резона писать Pylons Handbook, который будет повторять уже существующую документацию этих компонент. Документация, поставляемая вместе с Pylons, покрывает основные ключевые моменты использования этих компонент, содержит примеры и туториалы. Так что не пугайтесь, если вас отошлют на другой сайт.

Нет необходимости знать все компоненты “на зубок”, но чтобы правильно использовать Pylons, вам нужно понимать их основы. В дополнение к введению в Pylons Getting started и туториала QuckWiki, которые вы можете найти в документации к Pylons, желательно прочесть краткие введения в компоненты Pylons:

  • SQLAlchemy — SQL тулкит и ORM
  • Myghty - шаблоны
  • Mako — шаблоны, альтернатива Myghty
  • WebHelpers — набор Python-инструментов
  • Routes — как URLы ставятся в соответствие с контроллерами

Этот материал поможет вам в краткие сроки познакомиться с Pylons. Удачи в вашем первом проекте на Pylons!

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

Комментарии

31.01.2007 19:12 Юревич Юрий

Наконец что-то на русском появилось по Pylons. Спасибо pythy.

31.01.2007 23:51 Юревич Юрий

И это статья 2007 года? Видимо, Кристоф Хаас довольно давно с Джанго общался — оттуда ведь убрали магию. В крайнем случае — большинство магии :)

1.02.2007 0:04 Юревич Юрий

Да, эта статья свежая, 2007 года.

Да, после magic removal в Django магии стало меньше, но она все равно есть. Это особенно чувствуется, если поработать с другими инструментами.

1.02.2007 18:03 Юревич Юрий

А что вы скажете про Zope?

1.02.2007 20:25 Юревич Юрий

Пока я не вижу причин его изучать. Из известных мне преимуществ (acquisition, zodb, zpt, zinterface) ни одно не является (для меня) решающим… тем более zodb я использую(вал) и без всего Zope. Между делом почитываю книгу по Zope 3. Если найду интересные фичи, то может и попробую…

1.02.2007 20:27 Юревич Юрий

А можно ткнуть пальцем в какую-нить раздражающую “магию” в Джанго?

Форма комментирования для «Концепции Pylons»

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

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

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

1.02.2007 21:41 Юревич Юрий

На вскидку:
* неявный импорт management.py при syncdb — в документации ни слова
* неявный импорт settings.py
* использование переменной окружения как указание конфига

Ну и с сигналами в django неразбериха: не документировано, не понятно куда вставлять обработчики сигналов. Я видел, что их пихали и модели, и в виды…

6.02.2007 23:50 Юревич Юрий

Ну насчёт переменной окружения… ИМХО, это не магия, а вполне себе довольно стандартный способ в никсах указать многое.

А недокументированные сигналы — ну это точно не магия. ;) Но жаль, что документации официальной нету… И пока в рассылке не слышно, чтоб кто-то про доки сигналов заикался, если я ничего не пропустил… :(

6.02.2007 23:54 Юревич Юрий

Кстати, на мой взгляд довольно приятная штука у Django — это удачно сделанные темплейты. Они достаточно быстрые (на сайте Мако написано, что быстрее только Mako и Cheetah, при чём по сравнению с другими — несущественно) и в них нельзя запихнуть код на питоне.

А во всех остальных — это практически правило. В том же Mako в первом же примере такая фигня. :( Неправильно это, имхо, неправильно…

7.02.2007 8:09 Юревич Юрий

В итоге всё равно скатились на обсуждение Django ;-)

Кстати, на мой взгляд довольно приятная штука у Django — это удачно сделанные темплейты.

Были бы они отдельным, не зависимым от Django компонентом, да еще чтобы unicode умели…

Вопрос на засыпку: почему Бен Бангерт выделяет компоненты своего фреймворка (Pylons) в отдельные проекты (WebHelpers, AuthKit, Routes, Beaker), а Адриан Головаты сотоварищи (Django) - нет?

А “правильными Django-шаблонами” является Jinja .

7.02.2007 20:14 Юревич Юрий

> В итоге всё равно скатились на обсуждение Django ;-)

Сорри. ;)

> Вопрос на засыпку: почему Бен Бангерт выделяет компоненты своего фреймворка (Pylons)
> в отдельные проекты (WebHelpers, AuthKit, Routes, Beaker), а Адриан Головаты сотоварищи (Django) - нет?

Кто бы мне самому это рассказал… А у RoR они тоже выделены?

P.S.Насчёт Pylons — когда я весной среди тонн фреймворков разбирался, для меня это был второй по привлекательности проект просле Django. Но и сейчас я смотрю, и Django мне больше нравится. Хотя, может, надо поближе присмотреться…

5.04.2007 18:53 Юревич Юрий

Как ни печально констатировать, но полностью “нормальных” веб-фреймворков под python не существует. Ни один из них не является достаточно (пит|лак)оничным. В частности шаблоны не должны сильно зависеть от языка обработки (это означает, что логика должна быть вынесена вне шаблонного документа), должны быть быстры при обработке и выводе, кушать пропорциональное количество памяти (оптимимистичное заявление, что pylons _все_ держит в памяти, отнюдь не радует), хорошо поддерживать мультипоточность (то, что щас в Python заместо потоков — костыль какой-то), поддерживать быструю серилизацию для возможности создания кешей без нужды парсить и проверять на валидатность документ каждый раз при открытии (тот, кто говорит, что разбор XML документа работает быстрее загрузки серилизированного объекта — нагло врет).

На этом прерываюсь, но это еще не все :)

14.04.2007 17:12 Юревич Юрий

Web.py как всегда забыли.

18.04.2007 17:19 Юревич Юрий

Уж чего в Django мало, так это чёрной магии. Не в пример тому же Pylons.

20.04.2007 2:01 Юревич Юрий

Товарищи я не согласен с некоторыми местами в этой статье.
Прежде хочу заметить, что не являюсть питон-программистом, я изучаю перл, но питон мне после него кажется знакомым и маячит, как перспектива.
С чем не согласен:
— “нужен отдельный веб сервер”, сервер может быть и не отдельный, т.к. существует mod_perl который как раз глубоко интегрируется в апач, и мы получаем те же преимущества по управлению параметрами сервера, а местами наверно даже болшее преимущество.
— “веб сервер держит ваше приложение в памяти, целиком.” НЕ используем CGI, а пишем под mod_perl и эфективность повышается в десятки раз.

Замечу — это всего лишь неточности, которые могут создать неверную картину об обстановке вцелом.

P.S.в перл тоже есть фрейм-ворки и не один — их много: catalyst, Apache-JAF, Jifty, Maypole, mind.
Кстати, до этой статьи часто попадались на глаза тексты и статьи, что у Питон программистов вообще нет выбора и есть только один Ruby on Rails.

20.04.2007 8:06 Юревич Юрий

— “нужен отдельный веб сервер”, сервер может быть и не отдельный, т.к. существует mod_perl который как раз глубоко интегрируется в апач, и мы получаем те же преимущества по управлению параметрами сервера, а местами наверно даже болшее преимущество.

Основное, зачем (мне) нужен отдельный веб-сервер, это

— “веб сервер держит ваше приложение в памяти, целиком.” НЕ используем CGI, а пишем под mod_perl и эфективность повышается в десятки раз.

Создавая приложение под mod_perl/mod_python, мы привязываемся к конкретному серверу (Apache). Создавая WSGI-совместимое приложение, мы сами выбираем способ развертывания .

Кстати, до этой статьи часто попадались на глаза тексты и статьи, что у Питон программистов вообще нет выбора и есть только один Ruby on Rails.

Это у Ruby-программистов нет особого выбора — Ruby on Rails.

18.05.2007 4:32 Юревич Юрий

Огромное спасибо за такую приятную поразившую новичка статью. Неделю назад прочитал про django и на день позже про “вишенки”. Сегодня случайно услышал про pylons, и честно говоря получил просто огромное удовольствие и много нового узнал про сами движки и питон как язык программирования в частности. Просто ни разу не видел такой развернутой информации (понятной для новичка) относительно различных движков, написанных на питоне. Просто крайне приятно было читать про сравнительный анализ различных технологий построения движков. ОГРОМНОЕ спасибо.