RIA- приложение Fuzzle CMS* : разбор полётов

1. RIA-приложение Fuzzle CMS*:разбор полётов *Fuzzle CMS – система управления Flash-сайтом на базе Flex и PHP

2. История 1: прокси-классы

3. История 1: прокси-классы • Серверных классов может быть много: • Работа с файлами; • Работа со страницами; • Работа с фотогалереей; • Работа с настройками и т.д. • Прокси-классы абстрагируют вызовы процедур серверных классов; • Автоматически генерируются в AMFPHP!

4. История 1: прокси-классы • Пожелание 1: общая авторизация, автобиндинг;

5. История 1: прокси-классы • Пожелание 2: вызов функции «по исполнению» • callgetGallery(rootid:Object, onDataReceive: Function = null) • onDataReceive(result:Object):Object { return new XML(String(result)); } • Хорошо работает в случаях, когда нужно преобразовать, полученную строку в XML или список; • Позднее было понято, что Event-структура была бы логичнее; однако, текущее решение позволяет определять callback-функции проще.

6. История 1: прокси-классы • Пожелание 3: обработка состояний запроса (удался/не удался) • Создаются специфичные серверные функции, возвращающие статус запроса; • Теперь результат каждого запроса - массив

7. История 1: прокси-классы • Пожелание 4: кеширование!(хотя бы на время одной сессии) • Специальным статусом указываем о необходимости кешировать результат.

8. История 1: прокси-классы • Пожелание 5: создать постоянный кеш с обновлением через указанное время • Решение: автогенерацияSharedObject; • Пожелание 6: хочу управлять кешем! • Решение: набор специальных функций очистки кеша; вызов событий при вызове определенных функций; • Пожелание 7: отслеживание выполнения удаленных операций. • Решение: создание флага “isRemoteCall”, специальной процедуры errorHandler.

9. История 1: результат • Что мы получаем в результате автоматической генерации: • Единую аутентификацию; • Возможность автоматически использовать результаты запроса (автобиндинг); • Отслеживать и преобразовывать результаты; • Генерировать ошибки на сервере с автоматической обработкой на клиенте; • Кешировать результаты на время сессии/в постоянной памяти, управлять кешем при определенных событиях; • Отслеживать выполнение запроса (например, блокировать кнопки на время его выполнения) • Пример из жизни: клиентская часть одного из проектов включает 10000 строк кода. 6000 из них занимают прокси-классы.

10. История 2: модули и виджеты • Или как мы «налажали»  • Шаг 1: Fuzzle CMS – как модульная система; • Deep Linking (навигация через подмену строки браузера, SWFAddress) • В нашем случае: • /<имя модуля>/<параметр> • Предполагалось, что каждый модуль – отдельное Flex-приложение

11. История 2: модули и виджеты • Шаг 2: Внедрение модуля визуального редактирования страниц. • Позволяет пользователям размещать блоки на странице в произвольном порядке; • В него встроены следующие виды блоков: • Текстовый, SWF, картинка-со-ссылкой, видео. • Для каждого блока можно задавать оформление и анимацию появления на странице. • Клиенты довольны. Очень удобно, очень довольны.

12. Клиенты спрашивают: а почему, собственно, нельзя все сделать таскаемыми блоками? модули не пригодились…

13. История 2: модули и виджеты • Решение: создание библиотеки виджетов. • SWF-библиотека с внедренными классами; • 2 класса на виджет – собственно, визуальный блок, и его редактор. • Блок и редактор принимают на вход конфигурационный XML. • Редактор может включать в себя компоненты Fuzzle: выбор файла, ссылок и т.д.

14. История 2: модули и виджеты

15. История 2: модули и виджеты • Пример виджета(Картинка/SWF)

16. История 2: модули и виджеты • Пример редактора виджета(Картинка/SWF)

17. История 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>

18. История 2: модули и виджеты • Плюсы решения: • Разработка сторонними разработчиками виджетов и «прозрачное» их подключение; • Бонус для разработчиков: можно зашифровать виджет так, чтобы библиотека работала только на определенном сайте. • Простота разработки (два Flex-класса); • Унификация интерфейса для пользователя. • Минусы: • Необходимость подгружать ряд дополнительных файлов после загрузки движка; • Одно из решений: уменьшение объема путем исключения (External) стандартных Flex-библиотек. • Хуже работает DeepLinking, например, на фотогалереях (внутри блока изменения строки не предусмотрено) • Не работает стандартная локализация.

19. История 3: как подключать дизайн? • (и тут мы промахнулись) • Идея 1: каждый Flash-сайт уникален, и под каждый создается отдельный Flex-загрузчик с соответствующими меню, местом подгрузки модулей и т.д. • При этом поддерживаются «растягивающийся» дизайн.

20. История 3: как подключать дизайн? • На практике: • Появился Template1Loader, подгружающий «в себя» SWF-файл на задний план; • Он очень всем понравился, поскольку можно было создавать дизайн отдельно от Flex. • Template1Loader разрастался фичами, которые желательно было поддерживать и другими загрузчиками. • Код инициализации постоянно обновлялся, что требовало обновления всех загрузчиков и занимало кучу времени. • (Последнее) Идеология расстановки блоков вынудила отказаться от «растягивающихся» дизайнов.

21. Результат? Остался только один загрузчик, у которого мы решили сделать много параметров конфигурации 

22. История 3: дизайн

23. История 3: как подключать дизайн? фон • Как устроен дизайн? основной дизайн место подгрузки модулей

24. История 3: как подключать дизайн? • Как происходит взаимодействие с кодом? • Как сделать кнопку? • а) Делаем кнопку средствами Flash • б) Пишем следующий обработчик: • getClassByAlias("aliasXmLoader").xmLoader.goToURL("thissite://XmAdvPage-main/TestPage"); • Ядро доступно через getClassByAlias. Соответственно, доступны и разные его возможности.

25. История 3: как подключать дизайн? • Плюсы: • Простота разработки дизайна; • Минусы: • Наличие двух слоев (дизайна и содержимого страницы) приводит к тому, что вывод поверх содержимого страницы затруднен (например, при разработке выпадающего меню) • Сложность отслеживания разных событий (начала и конца анимации между страницами и т.д.)

26. Архитектура (целиком)

27. Результаты • Три истории: • Генерация клиентских классов позволяет здорово экономить время; • Людям нравится удобство и простота при создании: • Дополнительных модулей; • Дизайна. • Ради удобства они готовы поступиться функциональностью.

28. Полезные ссылки • Сайт системы: http://fuzzle-cms.ru/ • Создание и установка виджетов: • http://docs.fuzzle-cms.ru/Programmistu - документация программисту • http://docs.fuzzle-cms.ru/Programmistu/Sozdanievidzhetov - пример Flex-виджета • Интеграция дизайна: • http://docs.fuzzle-cms.ru/Designer - документация дизайнеру