Обзор фреймворка Fusebox
Есть такой фреймворк — Fusebox, простой и классный. Позиционируется как open source решение для разработки больших и сложных веб-приложений.
Вводная
Основная его задача — позволить разработчикам структурировать свой код согласно набора нехитрых соглашений, а также упростить и ускорить разработку приложений, в том числе за счет методологии FLiP (Fusebox Lifecycle Process).Разрабатывается этот фреймворк в первую очередь для ColdFusion (судя по тому, что релизы для этой платформы выходят раньше), а также для других языков, включая PHP. Текущая версия — 5.5; начиная с четвертой ветки стали использовать XML для файлов настроек (что имхо потенциально упрощает код-генерацию).
По сравнению с фреймворками вроде Symfony, где есть код-генераторы и всякие хелперы, выглядит уж очень простецки — здесь есть только:
- компактный движок;
- несколько соглашений о наименовании;
- специальная структура проекта;
- идея вложенных шаблонов;
- методология разработки FLiP;
- свой формат документации — FuseDoc.
Стуктура Fusebox-приложения
Опять же в отличие от Symfony, где application — это, например, frontend или backend aka админка, в Fusebox приложение приравнивается к проекту (т.е. задается всей папкой).Fusebox-приложение состоит из следующих основных компонентов: оператор выбора (switch), модуль (circuit), действие aka фьюзэкшн (fuseaction) и фьюз (fuse) как атомарная часть фьюзэкшена.
Оператор выбора определяет, какой модуль и какое действие в нем нужно выполнить. Делается это по значению специальной POST/GET-переменной fuseaction (начиная с версии 4, ее имя можно задавать произвольно) формата [circuit].[action], например, ’news.list’.
Фьюзэкшн является собирательным именем для целого ряда действий-фьюзов. Например, фьюзэкшн ’news.list’ из примера выше может последовательно инклудить файлы контроллера и шаблона для вывода новостей. Помимо этого можно выполнять внутренние запросы других фьюзэкшенов и буферизовать результаты их выполнения в переменную (например, залогинить юзера) или настроить перенаправление (сессия упала — долой из закрытой зоны).
Каждый фьюз, входящий во фьюзэкшн, выполняет какое-то одно действие: получает данные из БД, отправляет мыло или отображает блок данных. Имена фьюзов имеют различные префиксы в зависимости от назначения:
- act — (action) контроллер, обрабатывающий, скажем, данные формы и общающийся с БД;
- dsp — (display) шаблон, производит вывод данных;
- qry — (query) более редкий случай — содержит SELECT-запросы, которые можно вызывать из разных фьюзэкшенов;
- lay — (layout) более общий шаблон уровня модуля.
Предусмотрена такая вещь как pre/postfuseaction — распространенная идея, согласно которой можно задать какой-то код, который надо выполнить для любого фьюзэкшена в данном модуле — скажем, вывести хедер/футер, или при работе в админке на любой странице нужно проверять, залогинен ли пользователь. При этом можно указать, вызывать ли при этом pre/postfuseaction родительского модуля — если админка содержит в себе подмодули, все равно стоит проверять факт залогиненности юзера для каждого из них — т.о. это делается автоматически. Разумеется, похожая логика работает и для всего приложения — в конфиге есть разделы pre/postprocess, где можно указать глобальные фьюзэкшены, которые нужно вызывать при старте/останове приложения — скажем, в девелоперской версии вам надо очищать кэш после каждого запроса.
С точки зрения безопасности хороша идея единой точки входа — всегда вызывается index.php, меняется только значение фьюзэкшена. Таким образом не раскрываются пути к файлам приложения.
В четвертой версии введены два режима работы — development и production. Помимо того, что они отличаются политиками кэширования, их удобно использовать в разработке — вроде того, что в девелоперском режиме выводить дампы сессии на каждой странице, или настроить разный режим вывода ошибок. В пятой версии режимов больше, но суть осталась примерно та же.
Производительность повышается за счет того, что файлы настроек приложения и модулей парсятся, преобразуются из XML в PHP и кэшируются. В девелоперском режиме этот процесс производится при каждом запросе.
Есть такая приятная мелочь — массив $attributes, который представляет собой слияние (array_merge) массивов POST и GET (порядок слияния можно конфигурировать).
Если уж заговорили про приятные мелочи, стоит упомянуть переменные $self и $myself — «путь к index.php» и «путь к index.php с подставленным именем фьюзэкшн-переменной» соответственно. Хороши тем, что какие-то выкрутасы с URL’ами можно настраивать в одном месте — например, если вы захотите вручную добавлять идентификатор сессии во все URL’ы на сайте.
Паттерны во Fusebox-проекте
При всей своей простоте Fusebox реализует несколько паттернов. Самый очевидный — Model-View-Controller:- Бизнес-логика лежит в плагинах.
- Контроллер — это файлы act*.
- Темплейты — файлы dsp*.
Активно используется паттерн Декоратор: шаблон каждого модуля может вкладываться в родительский, т.о. получается матрешка — например, сначала сверху и снизу отрисовывается главное меню и главный футер сайта, затем слева отображается меню админки, и в центре — собственно, данные.
Минусы Fusebox
Из минусов хочется упомянуть то, что логику фьюза нужно смотреть в двух местах — ее можно писать как в act-файлах, так и в самомА еще меня раздражает, что в FuseDoc
Методология разработки FLiP
Отдельного упоминания заслуживает замечательная методология разработки — FLiP. Она основывается на двух наблюдениях:- В начале разработки пользователи еще не могут предоставить отзывы о проекте.
- В финале разработки уже поздно что-то кардинально менять с учетом их фидбека.
FLiP предполагает последовательное прохождение следующих этапов:
- определяются пользователи приложения и их цели;
- создается вайрфрейм (wireframe) — кликаемая модель приложения, которая далека от конечного результата, однако дает архитектору возможность увидеть, как пользователи достигают своих целей. Дизайн еще не прикручен, чтобы не отвлекать заказчика от оценки функционала;
- рисуется дизайн. Приложение внешне выглядит прямо как готовое, но функционала почти нет. Задача — удостовериться, что заказчик хочет приложение, которое выглядит именно так;
- архитектор создает модули и фьюзы и заполняет в них шапку документации FuseDoc, где описывает цель и задачи данного фьюза, а также входные и выходные переменные;
- после этого рядовые девелоперы не мудрствуя лукаво наполняют эти «черные ящики» реальным содержимым — кодом. Так как фьюзы и модули четко разграничены, работу над ними можно вести параллельно;
- после написания каждій фьюз проходит этап юнит-тестирования — проверку на правильное поведение. Идея в том, что даже если на проект будут брошены новые девелоперы, ничегошеньки не понимающие в проекте в целом, они смогут быстро въехать в работу над отдельными фьюзами.
Постскриптум
Из известных сайтов, использующих Fusebox, можно назвать MySpace.Ссылки:
Sergii Galashyn
Alexander Skakunov
anonymous
12 коментарів
Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.