1 / 28

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

RIA- приложение Fuzzle CMS* : разбор полётов. * Fuzzle CMS – система управления Flash- сайтом на базе Flex и PHP. История 1: прокси-классы. История 1: прокси-классы. Серверных классов может быть много: Работа с файлами; Работа со страницами; Работа с фотогалереей ;

ponce
Télécharger la présentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 - документация дизайнеру

More Related