Слайд 1 - Блог Fuzzle CMS

RIA-приложение Fuzzle CMS*:
разбор полётов
*Fuzzle CMS – система управления Flash-сайтом
на базе Flex и PHP
История 1: прокси-классы
История 1: прокси-классы
• Серверных классов может быть много:
– Работа с файлами;
– Работа со страницами;
– Работа с фотогалереей;
– Работа с настройками и т.д.
• Прокси-классы абстрагируют вызовы
процедур серверных классов;
• Автоматически генерируются в AMFPHP!
История 1: прокси-классы
• Пожелание 1: общая авторизация, автобиндинг;
История 1: прокси-классы
• Пожелание 2: вызов функции «по исполнению»
– callgetGallery(rootid:Object, onDataReceive: Function =
null)
– onDataReceive(result:Object):Object { return new
XML(String(result)); }
• Хорошо работает в случаях, когда нужно
преобразовать, полученную строку в XML или
список;
• Позднее было понято, что Event-структура была бы
логичнее; однако, текущее решение позволяет
определять callback-функции проще.
История 1: прокси-классы
• Пожелание 3: обработка состояний запроса
(удался/не удался)
– Создаются специфичные серверные функции,
возвращающие статус запроса;
– Теперь результат каждого запроса - массив
История 1: прокси-классы
• Пожелание 4: кеширование!(хотя бы на время
одной сессии)
– Специальным статусом указываем о необходимости
кешировать результат.
История 1: прокси-классы
• Пожелание 5: создать постоянный кеш с
обновлением через указанное время
– Решение: автогенерация SharedObject;
• Пожелание 6: хочу управлять кешем!
– Решение: набор специальных функций очистки
кеша; вызов событий при вызове определенных
функций;
• Пожелание 7: отслеживание выполнения
удаленных операций.
– Решение: создание флага “isRemoteCall”,
специальной процедуры errorHandler.
История 1: результат
• Что мы получаем в результате автоматической
генерации:
– Единую аутентификацию;
– Возможность автоматически использовать результаты
запроса (автобиндинг);
– Отслеживать и преобразовывать результаты;
– Генерировать ошибки на сервере с автоматической
обработкой на клиенте;
– Кешировать результаты на время сессии/в постоянной
памяти, управлять кешем при определенных событиях;
– Отслеживать выполнение запроса (например, блокировать
кнопки на время его выполнения)
• Пример из жизни: клиентская часть одного из проектов
включает 10000 строк кода. 6000 из них занимают
прокси-классы.
История 2: модули и виджеты
• Или как мы «налажали» 
• Шаг 1: Fuzzle CMS – как модульная система;
– Deep Linking (навигация через подмену строки
браузера, SWFAddress)
– В нашем случае:
• /<имя модуля>/<параметр>
– Предполагалось, что каждый модуль –
отдельное Flex-приложение
История 2: модули и виджеты
• Шаг 2: Внедрение модуля визуального
редактирования страниц.
– Позволяет пользователям размещать блоки на
странице в произвольном порядке;
– В него встроены следующие виды блоков:
• Текстовый, SWF, картинка-со-ссылкой, видео.
– Для каждого блока можно задавать оформление и
анимацию появления на странице.
• Клиенты довольны. Очень удобно, очень
довольны.
Клиенты спрашивают: а почему,
собственно, нельзя все сделать
таскаемыми блоками?
 модули не пригодились…
История 2: модули и виджеты
• Решение: создание библиотеки виджетов.
– SWF-библиотека с внедренными классами;
– 2 класса на виджет – собственно, визуальный
блок, и его редактор.
– Блок и редактор принимают на вход
конфигурационный XML.
– Редактор может включать в себя компоненты
Fuzzle: выбор файла, ссылок и т.д.
История 2: модули и виджеты
История 2: модули и виджеты
• Пример виджета (Картинка/SWF)
История 2: модули и виджеты
• Пример редактора виджета (Картинка/SWF)
История 2: модули и виджеты
• Как загружать библиотеки?
– К каждой библиотеке приписан
конфигурационный XML. В нем может быть
задано несколько виджетов, например:
<path>http://fuzzle/standart.swf</path>
<libName>Standart</libName>
<widget>
<classMain>com.fuzzle.standart.BlockText</classMain>
<classEditor>com.fuzzle.standart.BlockTextEditor</classEditor>
<title>Text block</title>
</widget>
История 2: модули и виджеты
• Плюсы решения:
– Разработка сторонними разработчиками виджетов и
«прозрачное» их подключение;
• Бонус для разработчиков: можно зашифровать виджет так, чтобы
библиотека работала только на определенном сайте.
– Простота разработки (два Flex-класса);
– Унификация интерфейса для пользователя.
• Минусы:
– Необходимость подгружать ряд дополнительных файлов после
загрузки движка;
• Одно из решений: уменьшение объема путем исключения (External)
стандартных Flex-библиотек.
– Хуже работает DeepLinking, например, на фотогалереях (внутри
блока изменения строки не предусмотрено)
– Не работает стандартная локализация.
История 3: как подключать дизайн?
• (и тут мы промахнулись)
• Идея 1: каждый Flash-сайт уникален, и под
каждый создается отдельный Flex-загрузчик
с соответствующими меню, местом
подгрузки модулей и т.д.
– При этом поддерживаются «растягивающийся»
дизайн.
История 3: как подключать дизайн?
• На практике:
– Появился Template1Loader, подгружающий «в себя»
SWF-файл на задний план;
– Он очень всем понравился, поскольку можно было
создавать дизайн отдельно от Flex.
– Template1Loader разрастался фичами, которые
желательно было поддерживать и другими
загрузчиками.
– Код инициализации постоянно обновлялся, что
требовало обновления всех загрузчиков и занимало
кучу времени.
– (Последнее) Идеология расстановки блоков вынудила
отказаться от «растягивающихся» дизайнов.
Результат? Остался только один
загрузчик, у которого мы решили
сделать много параметров
конфигурации 
История 3: дизайн
История 3: как подключать дизайн?
• Как устроен дизайн?
фон
основной
дизайн
место подгрузки
модулей
История 3: как подключать дизайн?
• Как происходит взаимодействие с кодом?
– Как сделать кнопку?
– а) Делаем кнопку средствами Flash
– б) Пишем следующий обработчик:
• getClassByAlias("aliasXmLoader").xmLoader.goToURL(
"thissite://XmAdvPage-main/TestPage");
• Ядро доступно через getClassByAlias.
Соответственно, доступны и разные его
возможности.
История 3: как подключать дизайн?
• Плюсы:
– Простота разработки дизайна;
• Минусы:
– Наличие двух слоев (дизайна и содержимого
страницы) приводит к тому, что вывод поверх
содержимого страницы затруднен (например,
при разработке выпадающего меню)
– Сложность отслеживания разных событий
(начала и конца анимации между страницами и
т.д.)
Архитектура (целиком)
Результаты
• Три истории:
– Генерация клиентских классов позволяет
здорово экономить время;
– Людям нравится удобство и простота при
создании:
• Дополнительных модулей;
• Дизайна.
– Ради удобства они готовы поступиться
функциональностью.
Полезные ссылки
• Сайт системы: http://fuzzle-cms.ru/
• Создание и установка виджетов:
– http://docs.fuzzle-cms.ru/Programmistu документация программисту
– http://docs.fuzzlecms.ru/Programmistu/Sozdanievidzhetov пример Flex-виджета
• Интеграция дизайна:
– http://docs.fuzzle-cms.ru/Designer документация дизайнеру