[Moscow.pm] PEF::Front - RFC

[PEF Secure]

Приветствую!

Прошу комментариев к моему веб-фреймворку. 

Репо: https://github.com/pef-secure/pef-front-psgi-dist
Wiki: https://github.com/pef-secure/pef-front-psgi-dist/wiki

Развёрнуто причины создания фреймворка попытался изложить тут: 
https://github.com/pef-secure/pef-front-psgi-dist/wiki/%D0%9F%D1%80%D0%B8%D1%87%D0%B8%D0%BD%D1%8B-%D0%B8-%D0%A6%D0%B5%D0%BB%D0%B8

Демонстрационное приложение: https://github.com/pef-secure/pef-front-demo
Посмотреть работу приложения можно по адресу: http://pef-demo.perlpowered.com

Очень коротко суть: меньше контроллеров, представление (View) умеет получать 
данные для генерации шаблона из модели самостоятельно, модель может быть 
локальной или удалённой.

Фреймворк может использовать одну или несколько удалённых моделей, а так же, 
иметь локальные обработчики. Фронтендов может быть несколько к одной удалённой 
модели. Разные фронтенды могут иметь разное предназначение, работать со своими 
собственными моделями. Например, несколько фронтедов работает с моделью 
"клиентский сайт", а отдельный фронтенд работает с моделью "администрирование 
сайта и клиентов". Релиз PEF::Core, реализующего удалённую модель, дело 
ближайших нескольких месяцев, идёт процесс перехода от POE к чистому EV.

Изначально, эта часть фронтенда была реализована на mod_perl2, но в связи с 
его застоем в плане адаптации к Apache httpd 2.4, было решено отказаться от 
mod_perl2 совсем и перейти на PSGI. Пристальное разглядывание внутренностей 
Plack/Dancer убедило меня в том, что "я могу лучше", поэтому, PSGI 
используется без Plack. Тривиальные тесты показывают, что при переходе от 
mod_perl2 к PEF::Front + uwsgi + Nginx скорость реакции фронтенда выросла 
значительно (вместо 10мс стало около 1мс в одних и тех же условиях). 

Основной API фреймворка достаточно стабилен, поскольку есть зависимые проекты, 
которые не должны сломаться при обновлениях. 

# Коротко суть. 

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

Автоматическая инсталяция URL для представлений позволяет начать работать над 
макетом страницы ещё до того, как программист модели изготовит необходимые 
методы, возвращающие реальные данные.

Методы модели автоматически доступны из шаблонов, AJAX, HTTP GET/POST. 

Существует "стандартная схема" URL, которая может быть модифицирована как 
угодно в настройках диспетчеризации.

# Возможности.

* ориентация на протокол PSGI
* язык шаблонов Template-Toolkit
* возможность иметь удалённую модель
* дополнительные функции шаблонизации, позволяющие получать данные из модели 
или манипулировать ответом
* отсутсвие отдельной сущности контроллеров, большая часть их функциональности 
декларируется в файлах формата YAML
* автоматизировнная схема назначения URL, с возможностью её модификации
* чёткое разделение обязанностей программистов фронтенда и бекенда
* декларативная настройка валидации входящих данных, редиректов, ожидаемых 
ответов модели
* поддержка загрузки файлов
* поддержка сессий
* поддержка авторизации по протоколу Oauth2
* поддержка локализации приложений

Главный недостаток на текущий момент -- слабая документация и слабое 
тестирование, но они так и останутся слабыми, пока не будет соратников. Над 
формальными тестами фреймворка работает человек, использующий фреймворк в 
своей работе. Эта работа ведётся в отдельном форке.
-- 
PEF Developer