Rich Internet Application и управление контентом

    Ныне модно говорить о Web 2.0. В то время как идея коллективного разума, заложенная в это определение его же автором Тимом О’Рейли, по-прежнему остается темой досужих разговоров, нельзя не заметить, что всемирная паутина меняется. Веб-приложения по удобству использования становятся все ближе к настольным приложениям. Данная тенденция с нарастающей прогрессией охватывает Интернет и уже сегодня можно говорить о наступлении эры веб-приложений нового типа, «обогащенных» интернет-приложений или RIA. Впрочем, популярность таких терминов как Web 2.0 и RIA столь высока, что разработчики спешат повесить привлекательные ярлычки на свои продукты, порой толком не разбираясь в том, что подразумевается под этими терминами. Так, что же такое RIA на самом деле?


    Термин Rich Internet Applications (RIA) впервые был упомянут в рекламных материалах компании Macromedia в марте 2002 года. Менеджеры Macromedia тем самым подчеркнули, что хорошо известная технология Flash – это не только способ получения красочных визуальных эффектов на сайтах, но и инструмент создания полноценных бизнес-приложений на базе Web. Статические страницы сайтов старого типа предоставляют информацию пользователю и имеют весьма скудные возможности, в сравнении настольными приложениями, для организации взаимодействия пользователя с этой информацией. Когда вы запрашиваете дополнительную информацию (выполняете навигацию по сайту) или передаете данные на сервер, происходит перегрузка страниц сайта. Это неудобно, но так же и не безопасно, так как в момент перегрузки страниц можно потерять данные (скажем, из-за утери соединения с сервером). Однако именно так устроен Web 1.0. Сервер получает инструкции, когда вы набираете адрес страницы или сохраняете данные в вебформе. На их основе сервер формирует страницу, которую вы затем увидите. В обогащенных интернет-приложениях перегрузки страниц не требуется. Когда вы нажимаете кнопку для получения дополнительной информации или для отправки данных, сервер получает соответствующие инструкции и возвращает на страницу результаты своей работы. Программа на странице получает ответ севера и изменяется соответствующим образом.

    К примеру, если вы просматриваете каталог продукции в электронном магазине старого образца вы будете вынуждены ожидать перегрузку и формирование новой страницы при каждом нажатии кнопки «следующие 20 товаров». На сайте, построенном в традициях RIA вы сможете запросить выборку товаров с 50-80 позиции или же всех товаров отвечающих заданному диапазону цен. При этом страница сайта будет оставаться неизменной, но список с товарами будет меняться при каждом новом запросе.

    Сегодня реализация «обогащенных» интернет-приложений возможна посредством AJAX, Adobe Flex, Windows Presentation Foundation, Flash, Java-апплетов, Java и некоторых декларативных языков, таких как XUL, MXML. Из всех перечисленных инструментов широчайшую популярность приобрели лишь AJAX и Flash – в первую очередь, благодаря их доступности. Причем, если создание приложений целиком во Flash весьма ресурсоемкий и дорогостоящий процесс, разработка с применением AJAX едва ли занимает больше времени, нежели разработка классических сайтов старого типа. В большинстве современных проектов Flash используется лишь по мере необходимости. Как, например, на сайте журнала Elle (http://www.elle.ru/).

    Уже в самом названии AJAX (асинхронный JavaScript и XML) отражена суть технологии. Она позволяет клиентской и серверной сторонам веб-приложения взаимодействовать асинхронно. Т.е. ваш браузер может обратиться к серверу в любой момент времени (скажем, когда вы навели мышь на ссылку в тексте) и, наоборот, сервер может передать данные браузеру в любой момент, а не только лишь тогда, когда запрашивается новая страница. Как это бывает на практике?

    Одно из наиболее популярных применений AJAX – реализация в Web технологии drag & drop («перетянул и оставил»). Вы наверняка уже видели сервисы виртуального рабочего стола, такие как www.netvibes.com, www.pageflakes.com, www.yourminis.com или, по крайней мере, www.pusk.ru. Они позволяют нам располагать виджеты (полезную информацию с других серверов) на экране, настраивать их размеры таким же образом, каким мы привыкли делать это с окнами Microsoft Windows.

    Данные возможности постепенно мигрируют и в бизнес-приложения. Так, к примеру, на портале www.atlas.cz пользователи могут настраивать стартовую страницу с той же легкостью, как и в случае виртуального рабочего стола.

    Благодаря возможности конструировать внешний вид страниц из заранее заготовленных дизайн-шаблонов, пользователи CMS (систем управления контентом) теперь меньше зависят от разработчиков их сайтов. Администратор CMS может расположить различные информационные блоки в рамках заданной страницы с помощью мыши, задать их размеры, цвет и прочие атрибуты и сохранить состояние страницы, чтобы пользователи сайта видели ее в заданном виде. Однако еще большие преимущества администраторам CMS дает Drag&Drop при управлении содержанием сайта. В современной CMS для того, чтобы задать новое положение для документа в структуре или же для записи в списке, достаточно лишь «зацепить» эту позицию мышью и «перетащить» на новое место. Точно так же, как это делается с файлами в Проводнике Microsoft Windows.

    Drag & Drop в контент менеджменте

    Как уже было сказано, в «обогащенных» интернет-приложениях нет необходимости загружать сразу все данные. Их можно будет «догрузить» тогда, когда они потребуются пользователю. Например, при переходе в интерфейс управления структурой сайта в CMS загружается лишь первый уровень дерева структуры. Однако если пользователь пожелает раскрыть какую-либо ветвь дерева, ее данные будут «догружены» в тот же момент.

    Данная возможность еще более востребована при управлении списками. Приложение возвращает в интерфейс лишь тот диапазон записей, который пользователь запросил. Более того, даже формы ввода данных обретают новые черты. В современных веб-приложениях всё чаще встречается форма ввода строки данных, известная благодаря популярному сервису Google Suggest. Как только вы начинаете набирать что-либо в этой форме, под ней появляется выпадающий список с запросами, содержащими набранную подстроку. Те, кому приходилось выбирать, скажем, производителя товаров посредством нескончаемого выпадающего списка в SELECT, могут оценить эффективность новой формы.

    AJAX позволяет реализацию форм настольных приложений

    Отсутствие необходимости перегрузки страницы при любом действии пользователя меняет представление о веб-интерфейсах. Вы можете вносить данные в нескольких формах на странице, размещенных, скажем, на различных «закладках». Затем все введенные данные можно одновременно отправить на сохранение. И обратите внимание: если отправленные данные по какой-либо причине (обрыв соединения с сервером, внутренняя ошибка и т.д.) не будут сохранены, интерфейс сообщит вам об этом и позволит повторить попытку. А ведь ненадежность передачи данных была одним из основных недостатков веб-интерфейсов старого образца.

    Очевидно, что помимо прочего, сайты эпохи RIA способны сообщать о состоянии процессов, о результатах выполнения процессов. В настоящее время уже является хорошим тоном, когда любой элемент, затронутый какими-либо процессами в системе, отражает их состояние в специальной панели. Допустим, если пользователь запросил новую выборку товаров в электронном каталоге, он вправе знать, что происходит в системе, начиная с этого момента и до момента получения вами списка с товарами. Если по какой-либо причине сервер не может вернуть вам запрошенные данные, вы должны получить сообщение об этом.

    Возможности RIA поднимают надежность и удобство использования систем управления контентом на новый уровень, уровень, ранее доступный лишь настольным приложениям. Однако следует помнить, что интерфейсы эпохи RIA способны взаимодействовать не только с собственным серверным программным обеспечением, но и со сторонними приложениями. Это обстоятельство позволяет надеяться, что нынешние CMS постепенно будут развиваться в сторону ECM (управление корпоративным контентом) и, соответственно, начнет сокращаться разрыв между сайтами компаний и информационными ресурсами их корпоративных сетей.

    В статье приведены примеры интерфейсов CMS Site Sapiens 3.0 (www.sitesapiens.ru)
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 23

      0
      Уже в самом названии AJAX (асинхронный JavaScript и XML) отражена суть технологии

      Незнай незнай.... многие используют тотже prototype.pereodicalupdater не для xml а для javascript
      вида [1,2,3,1,3,'Тут будет текст'] итд
        0
        Я сам пишу ныне все AJAX-базированные приложения исключительно на JSON. Скажем, JS код билиотеки управления деревом структуры с Drag&Drop и контекстным меню сократился почти в 2 раза, скорость работы приложения выросла раза в три, код легче понять (а это важно, так как для open source проекта пишется) и т.д. Однако в нас компании практикуется и XML для унификации контроллера, возможности разибрать его ответ в сторонних приложениях
          0
          Аналогично
            –1
            AJAX хорошо использовать по смыслу а не везде подряд! как нынче модно! браузеры пока еще не поддерживают (в план организации интерфейса) его...
            Допустим хочешь показать другу то, что увидел... а ссылка то не сменилась с момента захода на сайт!

            Мое мнение, AJAX хорошо в меру...
            Ждем поддержку браузерами аякса...
              0
              А при чем тут браузеры? Это, скорее, дело приложения. Да, конечно было бы здорово, если бы javascript-код мог бы менять урл в адресной строке без фактического перехода. Но и сейчас есть варианты обхода этой проблемы - делаем урлы с якорями, и повсюду пихаем ссылки permalink. В общем, жить можно ;)
                0
                Пишите на флеше :) все таки AS3 это ООП в отличие от JS.
                Нет головных болей от платформы/браузера...флеш либо установлен - либо его нет.
                  0
                  В общем случае:
                  - Флеш в разработке дороже (даже если брать среднюю цену на рынке)
                  - Флеш сам по себе тяжелее (я имею ввиду размер swf)

                  > флеш либо установлен - либо его нет.
                  Браузер установлен в подавляющем большинстве случаев.

                  > Нет головных болей от платформы/браузера...
                  Согласен... Это огромный плюс.
                    0
                    > флеш либо установлен - либо его нет.

                    Может в это сложно поверить, но я наелся досыта проблемами, возникающими с флешом в разных браузерах. Например, в ФФ 1.5 флешка высотой больше одного экрана не может корректно реагировать на мышь в промежуточных положениях скроллинга. В некоторых операх у флешки съезжает отображение текста и т.п. Так что не так все просто!
                      0
                      а кто сказал, что js это не ООП?
                      0
                      >>а ссылка то не сменилась с момента захода на сайт!
                      а для этого можно делать специальные штуки типа "ссылка на эту страницу"
                        0
                        А ты ее покажи пользователю? И заставь ее найти?
                        Что первым делом станет делать посетитель? Копировать то, что у него перед глазами (браузерную строку)...
                        Якори конечно выход, но урлы становятся крайне нечитаемыми...
                    0
                    а как сокращается размер передаваемой информации :)
                  0
                  и, наоборот, сервер может передать данные браузеру в любой момент, а не только лишь тогда, когда запрашивается новая страница


                  ну это вы, конечно, загнули! это каким же макаром сервер сам отправляет данные в браузер?
                    +1
                    Пока этого нет, но рождается :)
                    http://cometd.com/
                      0
                      По запросу браузера, асинхронно. :)
                      Поставил реакцию на приход данных и пусть пользователь делает что ему надо.
                        0
                        Имеется ввиду - когда нет явного запроса (Reverse AJAX). Конечно на стороне клиентского приложения регулярно совершаются обращения к серверу, но пользователь в этом не принимает участия. Для него это выглядит, так как если бы сервер вдруг постучался в браузер и заявил что лимит места на сервере закончился или что-либо еще.
                          0
                          Есть разные техники - как те, что тут упомянули (периодический опрос сервера), так и более "синхронные".

                          Например, ajax-приложение может делать запрос к серверу, а сервер - не отвечать сразу, а держать это соединение открытым, пока для этого клиента не появятся данные. Как только появилась информация для передачи клиенту - сервер отдает ответ и закрывает соединение. А клиент, получив информацию, тут же открывает новое соединение для ожидания новой порции данных (кстати, так работает внутренняя переписка на damochka.ru - но там не js, а java).

                          Как вариант - можно не закрывать соединение, а просто "подпихивать" очередные порции данных - но в этом случае усложняется реализация и возникает много дополнительных проблем.
                            0
                            А теперь представьте ресурс с большой посещаемостью, который будет должен держать сразу сотни "постоянных" соединений.
                              0
                              Ничего страшного. Обычный сервер Apache поддерживает 256 постоянных соединений, но простым жестом руки, изменяющим эту константу, можно добиться любого количества открытых соединений. Это часто используется в чатах, где 300-400 одновременных KeepAlive соединений вполне обычное дело. Но есть более эффективные техники, позволяющие получать тот же эффект с меньшими затратами.
                                0
                                Делать чат на апаче крайне накладно - поскольку апач каждое соединение обрабатывает в отдельном процессе (1.3 так делает всегда, да и 2.x обычно настраивают именно так). Для операционной системы эти сотни-тысячи процессов - очень большая нагрузка.

                                Поэтому для постоянных соединений единственный вариант - мультиплексирование, когда один процесс по очереди обрабатывает много соединений. Так работают web-серверы nginx, lighttpd и другие.
                                0
                                И в чем проблема? ;) Держат, еще как! На самом деле, держать кучу таких открытых соединений не трудно, если аккуратно с ними работать. Конечно, это должен быть не apache+cgi или apache+mod_php, а, чаще всего, какой-то отдельный демон, написанный на компилируемом языке.

                                Кстати, приходите на конференцию, в первый день Игорь Сысоев расскажет, как настроить FreeBSD для работы с 100-200 тысячами соединений.
                            0
                            РГЛаб начал PR-активности на Хабре... :)
                            Подскажите кто из вас под ником этим сидит?

                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                          Самое читаемое