Все публикации с тегом “WSGI

Werkzeug, Jinja и все-все-все

Давно хотел попробовать Colubrid на пару с Jinja. Теперь у Colubrid есть преемник — Werkzeug, от той же Pocoo team. И Jinja с той поры сильно поменялся, но обо всём по-порядку.

продолжить чтение

PasteDeploy: введение для разработчиков

Вторая статья про PasteDeploy, теперь уже для разработчика. Крайне рекомендую предварительно ознакомиться с первой статьей.

Итак, вы решили, что в вашем приложение неплохо бы использовать PasteDeploy. Это сделать очень просто, что я вам и продемонстрирую.

продолжить чтение

PasteDeploy: ликбез для пользователей

Продолжаем тему Paste. Сегодня разговор о PasteDeploy.

Вначале я просто думал перевести документацию по PasteDeploy, да что-то она какая-то замороченная, поэтому я попытаюсь изложить чуть попроще, а желающие могуть оценить оригинальный документ.

Зачем нужен PasteScript

Он нужен для одной единственной цели — дать способ конфигурировать WSGI-приложения, получая на выходе настроенное приложение в виде WSGI-приложения. Каламбур.

Еще раз. У вас есть некое WSGI-приложение. И необходима система конфигурирования. С ходу возникает идея просто хранить конфиг в отдельном модуле. Так, например, делает Django. Правда, он не использует явно модуль конфига, а подгружает его в свою настроечную систему, но не суть важно. Однако с этим подходом возникают проблемы, как только у вас возникнет желание компоновать WSGI-приложения в одном сайте с разными настройками. Например, Django в рамках одного проекта без специальных ухищрений не даст вам возможности использовать для блога одну БД, а для форума — другую. PasteDeploy худо-бедно (худо-бедно, потому что Ян Бикинг сделал упор на гибкость несколько в ущерб простоте, да и документация несколько хромает) решает эту проблему. Он дает возможность thread-safely настраивать WSGI-приложения.

продолжить чтение

WSGI, Paste

Продолжим работать с WSGI. Сегодня поговорим о Paste.

продолжить чтение

Две вишенки для гиков

Я не использую CherryPy, и в ближайшем будущем не планирую. Но эти два проекта привлекли своей нестандартностью.

RhubarbTart — WSGIsh CherryPy

RhubarbTart — это “стиль CherryPy на WSGI-движке”. То есть внешний API от CherryPy, но сделано на Paste.

Слово автору — Джулиану Краузе:

Q. Зачем еще один фреймворк?
A. RhubarbTart не новый фреймворк, это комбинация двух существующих фреймворков: пользовательский API и структура кода CherryPy, и инфраструктура Paste. Пересмотр старых вещей ради создания новых — необходимое условие эволюции.

Q. Получится ли просто поместить свой CherryPy-код в RhubarbTart?
A. Скорее всего нет. Хотя RhubarbTart по возможности использует имена и методы CherryPy, он не реализует все возможности CherryPy. Больше всего нареканий к тому, что не реализованы фильтры. Мы надеемся, что большинство фильтров можно заменить декораторами или WSGI middleware.

TurboGears new traversal — Cherrie Nevow

TGNewTraversal — управление URLами в стиле Nevow в TurboGears/CherryPy-приложениях.

Вот что говорит Даг Винтер о своём проекте:

Если вы создаете крупное, сложное приложение, вам нужен полный контроль над обходом (имеется ввиду обход методов контроллера при определении, какой метод будет “работать” для данного URLа, англ. traversal — прим. pythy), и CherryPy не дает такой возможности. Для того, чтобы механизм обхода нормально работал, необходимо зафиксировать компоненты URLа. Если же вы хотите, чтобы компоненты URLа могли меняться, то придется писать много кода, большая часть которого — “борьба” с CherryPy.

По мне это большой недостаток приложения, которое в остальном весьма приятно. […]

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

Так что встречайте TGNewTraversal. Я взял код механизма обхода из Nevow, на мой взгляд, это лучший способ обхода. Я немного “допилил” его для большей дружелюбности к CherryPy. Совсем немного кода нужно для того, чтобы приобщиться к грамотной концепции обхода из Nevow.