Pyramid (веб-фреймворк)

Pyramid
Тип	Программный каркас веб-приложений
Разработчики	Бен Бангерт, Джеймс Гарднер
Написана на	Python
Операционная система	Кроссплатформенный
Первый выпуск	декабрь 2010 г.
Последняя версия	2.0.2 (25 августа 2023)
Репозиторий	github.com/Pylons/pyramid
Лицензия	Repoze Public License
Сайт	pylonsproject.com

Pyramid (англ. pyramid — пирамида) — программный каркас (фреймворк) для разработки веб-приложений с открытым исходным кодом, написанный на языке Python в рамках проекта Pylons.

История

На создание Pyramid оказали влияние такие фреймворки, как Zope, Pylons и Django. Код Pyramid разрабатывался в проекте repoze.bfg, а название поменялось в результате слияния проектов BFG и Pylons.

Основные принципы и понятия

Дизайн Pyramid основан на следующих принципах:

• простота,
• минимализм,
• документированность,
• скорость,
• надёжность,
• открытость.

В защиту своего дизайна авторы Pyramid написали довольно большой документ, который призван развеять мифы о фреймворке. Например, на критику модели MVC в Pyramid следует подробное объяснение, что MVC «притянут за уши» к веб-приложениям. Следующая цитата хорошо характеризует подход к терминологии в Pyramid:

Мы считаем, что есть только две вещи: ресурсы (resource) и виды (view). Дерево ресурсов представляет структуру сайта, а вид представляет ресурс. Шаблоны (template)

в реальности лишь деталь реализации некоторого вида: строго говоря, они не обязательны, и вид может вернуть ответ (response) и без них. Нет никакого "контроллера" (controller): его просто не существует. "Модель" (model) же либо представлена деревом ресурсов, либо "доменной моделью" (domain model) (например, моделью SQLAlchemy), которая вообще не является частью каркаса. Нам кажется, что наша терминология более разумна при существующих ограничениях веб-технологий.

Оригинальный текст (англ.)

...[We] say there are two things: resources and views. The resource tree represents a site structure, the view presents a resource. The templates are really just an implementation detail of any given view: a view doesn’t need a template to return a response. There’s no “controller”: it just doesn’t exist. The “model” is either represented by the resource tree or by a “domain model” (like a SQLAlchemy model) that is separate from the framework entirely. This seems to us like more reasonable terminology, given the current constraints of the web.

Возможности

Основными преимуществами Pyramid являются:

• возможность написать приложение в одном файле;
• конфигурация, основанная на декораторах;
• формирование URL на ресурсы;
• обслуживание запросов на статические файлы;
• панель инструментов для отладки приложения прямо в браузере;
• гибкая настройка отладки;
• дополнительные модули;
• виды (view) на основе как классов, так и функций;
• конфигурирование файлов-ресурсов (assets), то есть, файлов проекта, не являющихся файлами с исходным кодом на Python;
• расширяемые, взаимозаменяемые шаблоны (template);
• система событий;
• встроенная интернационализация (i18n);
• кэширование HTTP;
• встроенная поддержка сессий;
• виды для исключений;
• нет необходимости в одиночках (singleton);
• предикаты видов и множественные виды для маршрута (route);
• управление транзакциями, в том числе при работе сразу с несколькими базами данных;
• расширяемость конфигурации через механизм включения (include);
• гибкая, расширяемая аутентификация и авторизация;
• возможность обхода (traversal) дерева ресурсов;
• автоматизация повторяющейся конфигурации;
• 100 % покрытие кода тестами;
• поддержка пользователей (особенно начинающих) силами сообщества;
• высокая документированность;
• почти все компоненты перенесены и работают в Python3.2.

Использование каркаса для разработки приложения

Хотя не составляет большой трудности написать Pyramid-приложение (проект) с нуля, Pyramid имеет инструменты для инициализации кода нового приложения по выбранному шаблону, или, в терминологии Pyramid, каркасной структуре (англ. scaffolds). Например, в поставке имеются каркасные структуры для проектов, использующих ZODB или SQLAlchemy.

Проект — это каталог, содержащий по крайней мере один пакет на Python.

Типичная структура каталога для небольшого проекта:

MyProject/
|-- CHANGES.txt
|-- development.ini
|-- MANIFEST.in
|-- myproject
|   |-- __init__.py
|   |-- static
|   |   |-- favicon.ico
|   |   |-- logo.png
|   |   `-- pylons.css
|   |-- templates
|   |   `-- mytemplate.pt
|   |-- tests.py
|   `-- views.py
|-- production.ini
|-- README.txt
|-- setup.cfg
`-- setup.py

Приведённую структуру, как следует из документации, не следует сильно изменять, так как это может помешать другим разработчикам быстро ориентироваться в коде проекта. Тем не менее, растущий проект может потребовать некоторых изменений. Например, виды, модели (если они используются) и тесты можно, разбив на модули, перенести соответственно в подкаталоги views, models и tests (не забыв снадбить их файлом __init__.py).

Проект может, например, находиться в составе buildout (скажем, в каталоге src), который собирает все необходимые компоненты вместе. Совсем необязательно, чтобы Pyramid-проект состоял из одного пакета. Величина проекта ограничивается только достаточностью знаний разработчиков о возможностях Pyramid.

Pyramid может работать с любым WSGI-сервером. Проекты, созданные по готовым каркасным структурам, используют сервер Waitress.

Диспетчеризация URL и обход дерева ресурсов

Каждый поступающий на сервер приложений Pyramid запрос (request) должен найти вид (view), который и будет его обрабатывать.

В Pyramid имеется два базовых подхода к поиску нужного вида для обрабатываемого запроса: на основе сопоставления (matching), как в большинстве подобных фреймворков, и обхода (traversal), как в Zope. Кроме того, в одном приложении можно с успехом сочетать оба подхода.

Простейший пример с заданием маршрута (заимствован из документации):

# Здесь config - экземпляр pyramid.config.Configurator
config.add_route('idea', 'site/{id}')
config.add_view('mypackage.views.site_view', route_name='idea')

Использование обхода лучше проиллюстрировать на небольшом примере:

from wsgiref.simple_server import make_server
from pyramid.config import Configurator
from pyramid.response import Response

# Класс некоторого ресурса
class Resource(dict):
    pass

# Дерево ресурсов (жёстко закодированное) в фабрике корня
def get_root(request):
    return Resource({'a': Resource({'b': Resource({'c': Resource()})})})

# Вид-для-вызова, который умеет показывать ресурс Resource (в context)
def hello_world_of_resources(context, request):
    output = "Ресурс и его дети: %s" % context
    return Response(output)

if __name__ == '__main__':
    config = Configurator(root_factory=get_root)
    config.add_view(hello_world_of_resources, context=Resource)
    app = config.make_wsgi_app()
    server = make_server('0.0.0.0', 8080, app)
    server.serve_forever()

В этом примере иерархия для обхода жестко задана в методе get_root с помощью вложенных словарей, тогда как реальные приложения должны сами определять необходимый доступ по ключам (метод __getitem__ помогает организовать такой доступ). В коде также присутствует корневая фабрика, с которой собственно и начинается обход узлов (node) дерева ресурсов. Вид-для-вызова (view callable) представлен функцией hello_world_of_resources. Говоря несколько упрощённо, на основе URL запроса в результате обхода иерархии Pyramid находит ресурс и применяет к нему «наилучший» вид-для-вызова (в нашем примере — он единственный).

Конфигурирование

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

Императивное конфигурирование производится вызовами методов конфигуратора непосредственно перед стартом приложения.

Декларативное конфигурирование задается декораторами видов. Перед запуском приложение «сканируется» на предмет конфигурационных параметров методом scan() конфигуратора. Пример из документации:

from pyramid.response import Response
from pyramid.view import view_config

@view_config(name='hello', request_method='GET')
def hello(request):
    return Response('Hello')

Оба метода конфигурирования полностью взаимозаменяемы.

Желающие могут использовать для конфигурирования ZCML, установив соответствующий пакет.

Генерация HTML

В Pyramid можно использовать различные движки для генерации HTML. Так, Chameleon и Mako входят в поставку. Кроме них, можно подключить и другие, например, Jinja2.

Работа с формами может осуществляться, например, с помощью троицы Peppercorn-Colander-Deform.

Пример

Одно из наиболее простых приложений для Pyramid:

from wsgiref.simple_server import make_server
from pyramid.config import Configurator
from pyramid.response import Response

def hello_world(request):
   return Response('Hello %(name)s!' % request.matchdict)

if __name__ == '__main__':
   config = Configurator()
   config.add_route('hello', '/hello/{name}')
   config.add_view(hello_world, route_name='hello')
   app = config.make_wsgi_app()
   server = make_server('0.0.0.0', 8080, app)
   server.serve_forever()

Применение

• Проект KARL  (неопр.). Архивировано из оригинала 29 апреля 2012 года.

Ссылки

• Chris McDonough, The Pyramid Web Application Development Framework (PDF) (англ.)
• Pyramid Cookbook (англ.)
• Pyramid Single File Tasks Tutorial (англ.) Небольшое учебное руководство по Pyramid

Литература

• Chris McDonough. The Pyramid Web Application Development Framework: Version 1.0. — Agendaless Consulting, 2011. — 596 с. — ISBN 978-0615445670.