Вводная

Основная его задача — позволить разработчикам структурировать свой код согласно набора нехитрых соглашений, а также упростить и ускорить разработку приложений, в том числе за счет методологии 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:

1. Бизнес-логика лежит в плагинах.
2. Контроллер — это файлы act*.
3. Темплейты — файлы dsp*.

Активно используется паттерн Декоратор: шаблон каждого модуля может вкладываться в родительский, т.о. получается матрешка — например, сначала сверху и снизу отрисовывается главное меню и главный футер сайта, затем слева отображается меню админки, и в центре — собственно, данные.

Минусы Fusebox

Из минусов хочется упомянуть то, что логику фьюза нужно смотреть в двух местах — ее можно писать как в act-файлах, так и в самом XML-конфиге модуля, ибо конфиг там навороченный, умеет и условия проверять, и циклы делать, и другие модули вызывать. По опыту могу сказать, что проще всего просто договориться, где какие вещи пишутся.

А еще меня раздражает, что в FuseDoc (XML-шапка в каждом фьюзе, описывающая его назначение) описания пишутся от первого лица — "I delete a genre from the system"…

Методология разработки FLiP

Отдельного упоминания заслуживает замечательная методология разработки — FLiP. Она основывается на двух наблюдениях:

1. В начале разработки пользователи еще не могут предоставить отзывы о проекте.
2. В финале разработки уже поздно что-то кардинально менять с учетом их фидбека.

FLiP подразумевает, что интерфейс пользователя aka фронтенд строится ДО того, как будет написан код. Т.о. юзеры могут поиграть с приложением еще до того, как проект будет сделан — и только после этого разработчики начинают "заливать” кодом одобренные пользователями фичи.

FLiP предполагает последовательное прохождение следующих этапов:

• определяются пользователи приложения и их цели;
• создается вайрфрейм (wireframe) — кликаемая модель приложения, которая далека от конечного результата, однако дает архитектору возможность увидеть, как пользователи достигают своих целей. Дизайн еще не прикручен, чтобы не отвлекать заказчика от оценки функционала;
• рисуется дизайн. Приложение внешне выглядит прямо как готовое, но функционала почти нет. Задача — удостовериться, что заказчик хочет приложение, которое выглядит именно так;
• архитектор создает модули и фьюзы и заполняет в них шапку документации FuseDoc, где описывает цель и задачи данного фьюза, а также входные и выходные переменные;
• после этого рядовые девелоперы не мудрствуя лукаво наполняют эти "черные ящики” реальным содержимым — кодом. Так как фьюзы и модули четко разграничены, работу над ними можно вести параллельно;
• после написания каждій фьюз проходит этап юнит-тестирования — проверку на правильное поведение. Идея в том, что даже если на проект будут брошены новые девелоперы, ничегошеньки не понимающие в проекте в целом, они смогут быстро въехать в работу над отдельными фьюзами.

По терминологии System Development Lyfe Cycle, FLiP относится к rapid prototyping.