Общее описание

Решаемые задачи

Построение гибких масштабируемых платформонезависимых корпоративных приложений с Rich Client интерфейсом.

Введение в платформу m3

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

Примечание

Вьюшка - это метод в Django принимающий HttpRequest и возвращающий HttpResponse. Как правило вьюшки находятся в модуле views.py приложения. Writing views

При поступлении запроса, он сначала проходит через все подключенные Middleware, затем проверяется на соответсвие выражениям из urlpatterns. В итоге либо вызывается соответсвующая вьюшка, либо генерируется исключение 404. Так вкратце работает механизм разруливания запросов в Django URL dispatcher

Такой подход очень прост и вполне подходит для приложений уровня homepage ;) Но для корпоративных приложений появляются новые требования:

1. Отсутсвие вшитых в программу адресов (URL)
2. Изменение адресов на ходу
3. Перехват выполнения перед вьюшкой и после вьюшки
4. Автоматическое извлечение и контроль входных параметров вьюшки
5. Гибкое встраивание нового функционала

Концепция

Чтобы покрыть недостающий функционал URL dispatcher было принято решение - отказаться от вьюшек и использовать их только как точки входа в приложение. Т.е. одно приложение - одна вьюшка, в которую приходят все запросы приложения. Далее будем называть её - вьюшка контроллера.

Вьюшки были заменены классами Action (экшены). Экшены аналогичные по смыслу и стремящиеся к одной цели, сгруппированы в классы ActionPack (экшенпаки). Таким образом экшены и паки представляют собой дерево, каждый узел которого имеет свой кусочек адреса. Путь от корня до конечного экшена является полным адресом, аналогичным адресу в URL dispatcher.

Связующим звеном между деревом экшенов и вьюшкой котроллера, является класс ActionController. Он хранит экшенпаки и отвечает за обработку запросов. Как правило контроллер бывает один на приложение.

Схема формирования адресов:

Диаграмма обработки запроса:

Самый первый запрос к вьюшке контроллера вызывает метод populate() в ControllerCache. Этот класс отвечает за хранение глобального списка контроллеров и начальную инициализацию дерева экшенов.

После первичного формирования дерева экшенов и контроллеров, запрос отправляется к конкретному котроллеру приложения. Получив сырой запрос, он разбирает его и проходит по дереву экшенов в поисках нужного. Если не находит, то генерирует исключение 404. Если находит то выполняет все встретившиеся на пути, от корня до экшена, методы pre_run(). Выполнив экшен, в обратном порядке выполняются все методы post_run(). Причем если хоть один из них вернул результат отличный от None, обработка прерывается и результат уходит наружу, во вьюшку контроллера.