🏆 Рейтинг ІТ-роботодавців 2018: вже зібрано більше 13 000 анкет. Оціни свою компанію!
×Закрыть

Обзор фреймворка Fusebox

Есть такой фреймворк — Fusebox, простой и классный. Позиционируется как open source решение для разработки больших и сложных веб-приложений.

Вводная

Основная его задача — позволить разработчикам структурировать свой код согласно набора нехитрых соглашений, а также упростить и ускорить разработку приложений, в том числе за счет методологии FLiP (Fusebox Lifecycle Process).

Разрабатывается этот фреймворк в первую очередь для ColdFusion (судя по тому, что релизы для этой платформы выходят раньше), а также для других языков, включая PHP. Текущая версия — 5.5; начиная с четвертой ветки стали использовать XML для файлов настроек (что имхо потенциально упрощает код-генерацию).

По сравнению с фреймворками вроде Symfony, где есть код-генераторы и всякие хелперы, выглядит уж очень простецки — здесь есть только:Fusebox powered

  • компактный движок;
  • несколько соглашений о наименовании;
  • специальная структура проекта;
  • идея вложенных шаблонов;
  • методология разработки 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*.
With Fusebox

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

Минусы 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.

Постскриптум

Из известных сайтов, использующих Fusebox, можно назвать MySpace.

Ссылки:

P.S. Профайл одного из авторов Fusebox Хала Хелмса (Hal Helms) есть в LinkedIn.
LinkedIn

12 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Стаття по духу близька до Вікіпедії, тобто для отримання загальних даних достатньо. Хоча для розробників можна було б трохи більше написати, скажімо приклади конфігурування, гнучкість роботи circuit’ів та подібне. Плюс, в гілці 5.х є чимало нового і цікавого, скажімо ті самі лексикони. Додало б ваги при порівнянні з іншими фреймворками. Загалом, мене fusebox дуже приваблює інтуітивністю в побудові структури сайту — все логічно і працює так як мусить. Знову ж, швидкість розробки цілком задовільна, особливо опісля деякого часу роботи з ним, коли накоплюється код, котрий можна повторно використовувати.

Да, там нет никакого ORM:

По сравнению с фреймворками вроде Symfony, где есть код-генераторы и всякие хелперы, выглядит уж очень простецки

Поэтому и пишут в коментах, что он якобы устарел — конечно, в наше время, когда корабли бороздят, без генерации админки и ОО-подхода для написания SQL никуда. Хотя на самом деле те, кто юзает Fusebox, не чураются указанных благ цивилизации — просто они вольны их сами выбирать и прикручивать, а в готовых фреймворках высокого уровня это не всегда возможно/просто.Как используется Fusebox на MySpace, можно посмотреть здесь.Ссылку поправил, спасибо.

Ссылка на Fusebox в Википедии битая.

Вообще, MySpace уже давно уходит от ColdFusion, и у них сейчас практически все на.NETТак что, мне не особо понятно, как там используется FuseboxИнтересно было бы узнать, какие механизмы для работы с базами данных используются в этом фреймворке. (ORM? Или все, чего угодно?)

2 Скакунов АлександрЕсли я правильно понял, то в Fusebox нифига автоматизации нету, зато сама по себе архитектура приятная и выглядит это не как готовый инструмент, а скорее, конструктор «сделай сам». Как в этом случае со скоростью разработки? Просто я с таким подходом видел уже для php CodeIgniter (кстати, у нас изначально ж админки на нем были) и очень его критиковал, потому что с одной стороны у тебя есть фреймворк, а с другой — нифига не автоматизирует рутинные операции:)

noname: CakePHP — отличный выбор, если он позволяет все, что тебе нужно. То же самое с любым другим фреймворком.Александр Локшин: именно то, что много в Fusebox нет, например, автогенерируемых админок, имхо является его достоинством. Ты сам ругал на чем свет стоит, что в Симфони захардкожено использование кривового Propel ORM — в Fusebox этого нет, ты сам себе архитектор.

лично я остановил свой выбор на CakePHP и довольно давно с ним работаю и не имею никаких нареканий.кроме тогостроить проекты визуально — ЭТО ПЛОХО %username%

noname: согласен, что в век код-генераторов Fusebox кажется старичком (ударение на «кажется» ). Однако мнится мне, что «когда в руках молоток, все кажется гвоздем».Более того, проекты под Fusebox можно строить визуально.И спроси тех, кто плотно юзает Симфони, такая ли уж это панацея:):):)

Уверен, сравнивать фреймворки вполне корректно, пусть они, даже, будут для разных ниш, просто нужно упоминать что для чего подходит.Например, в PHP резонно сравнивать FuseBox с Symfony, Limb, Zend Framework (да-да, я знаю что это на самом деле не фреймворк), CakePHP. В Пайтоне с Django, Pylons, Turbo Gears, в руби с RoR, в джаве с Struts-2, SEAM, Spring (MVC)...Я, например, сейчас делаю для себя маленький проектик на Django и хотел бы знать, чем FuseBox лучше:)

Как говорит один мой знакомый;)

чем больше шкаф, тем громче падает

А вообще для нормального сравнения уточни слово «другие» — с кем меряцца будем? Многие фреймворки сравнивать между собой некорректно.

А ничем он не лучше. Ключевое слово — «Разрабатывается этот фреймворк в первую очередь для ColdFusion». Для PHP он явно морально устарел. Я не понимаю, например, зачем в век кейка и симфонии использовать фьюзебокс, кроме как усложнять себе жизнь. Да и вообще если бы не колда, он бы уже наверное умер...

После прочтения статьи появляется четкий вопрос, так чем же fusebox лучше чем другие?:)

Подписаться на комментарии