Велосипед: альтернатива iframe на jQuery.ajax как инструмент разработки mash-up приложений. Есть ли смысл?

Всем привет! Хочу предложить вниманию сообщества технический механизм, позволяющий без лишних усилий сделать iframe-подобное приложение, работающее на ajax. В качестве основы использованы jQuery ^[1] и easyXDM ^[2].

Техническое описание, прототип, предположения о возможных вариантах использования и сомнения под катом.

Прежде всего, хочу сказать, что в статье под мэшапом я подразумеваю не общее понятие,
а конкретный, частный случай. Когда нужно, работающее на одном домене веб-приложение
( сервис ) — встроить в другое ( площадка ).
Пользователь находится на странице площадки и может взаимодействовать с сервисом.

Недостатки существующих решений

iframe

• Не изменяется url в строке браузера, при перемещениях внутри iframe.
• Нужно что-то делать дополнительно, чтобы изменялась высота iframe автоматически по содержимому.
• Нужно сохранять текущее положение пользователя в сессии, чтобы при нажатии на F5 показывалась последняя страница на которой был пользователь, а не главная страница сервиса.
• Нужно следить чтобы ссылки на внешние сайты открывались в target="_parent" или target="_blank", иначе внешний ресурс тоже откроется внутри iframe, и это будет выглядеть странно.
• Нужно продумывать логику клика в режиме “Открыть в новой вкладке”, чтобы был автоматический редирект на соответствующую страницу площадки.
• Возникают ограничения на размер при отображении больших popup блоков, типа картинок в lightbox.
• Не все поисковые машины могут индексировать содержимое iframe.
• Сложности при организации общей авторизации.

Домен третьего уровня на сервере сервиса

• Необходимость создателям сервиса делать разработку под каждую конкретную площадку ( Собирать шапку, подвал, оформление каждой конкретной площадки )
• Дополнительные усилия со стороны площадки по регистрации домена третьего уровня.
• Необходимость обновления шапки-подвала всвязи с развитием площадки.
• Сложности при организации общей авторизации.

Предлагаемое решение позволяет быстро организовать мешап из уже работающего приложения или легко создать новое.

Демо прототипа

http://mashups.ru/demo ^[3]

Никак не тестировал под Mac :(
Это сервис ( обычное php приложение, использующее различные веб-механизмы ) и различные тестовые площадки, на которые встраивается сервис. Имеются php исходники сервиса, в них в комментариях указаны моменты, которые необходимы, чтобы он работал как мешап ( будут описаны далее в статье, в коде в комментариях будут отмечены как #for_mashup# ). Хостинг ^[4] находится на другой стороне планеты (есть реальные http задержки), это позволяет в некоторых браузерах увидеть невооруженным глазом преимущество ajax в скорости перед обычным web приложением. Подразумевается не первое открытие страницы, а последующие переходы по ссылкам сервиса.

Технические моменты

Серверная часть сервиса. Чтобы все заработало, необходимо в серверную часть приложения сервиса добавить специальный код, который подменит обычный ответ сервера на ответ jsonp. Например ответ сервиса на GET запрос:

<div>hello world</div>

Будет заменен на

callback_function( { "content": "<div>hello world</div>" } );

А POST ответ на

<script>parent.callback_function( { "content": "<div>hello world</div>" } );</script>

Эти подмены позволяют посылать кроссдоменные ajax запросы на сервер сервиса с браузера, находящегося на странице платформы. Таким же образом передается location для случая имитации 301 HTTP ответа сервиса. Например:

callback_function( { "location": "/postSuccess/" } );

В языке php такая подмена легко реализуется с помощью навешивания output callback через функцию ob_start. Непосредственно для разработчика сервиса, достаточно будет в скрипте который выполняется на всех страницах сделать дополнительный include специального скрипта, который внутри себя все это сделает.

Необходимо положить в определенное место swf файл для easyXDM, чтобы приложение работало в браузерах < IE8.
Также разместить специальный php файл serviceProvider, в нем определяется необходимый js, css обвес для сервиса плюс происходит работа с сессией.

Серверная часть площадки.Добавление JS кода на страницу, как добавление кода баннерной системы.

Клиентская часть. На страницу сервиса добавляется JS библиотека на основе easyXDM ^[2], которая делает следующее:

• Подменяет атрибуты href и action тегов A и FORM соответственно, в приходящем с сервиса HTML коде.
• Подменяет jQuery методы ajax, методы работы с DOM.
• Создает аналог объекта window.location.
• Создает окружение взаимодействия с платформой.

Все, кроме аналога window.location будет работать в мешапе так же как в самостоятельном веб приложении.
С window.location проблема, его нельзя подменить. Поэтому чтобы в сервисе использовать window.location, нужно обращаться к MU.location — его аналогу, обеспечивающему работу в рамках мэшапа. Но обеспечить работоспособность и сервиса как самостоятельное приложение и как мешап достаточно просто.

...
<head>
	<script>var MU = window;</script>
</head>
...
<a href="#" onclick="MU.location.href = '/link/'; return false;">ссылка</a>

Т.е. определить глобальную переменную MU как window. В рамках мешапа специальный js скрипт подменит ее на нужный объект, а без подмены она будет работать как обычный window.

Также, если использовать версию совсем без iframe тега, есть проблема обращения к методам ajax и DOM jQuery. По сути на странице оказывается две версии методов jQuery, одна работающая в рамках платформы, другая — работающая в рамках сервиса.
Пока есть такое интерфейсное решение:

$.muDom();

и после этого любое обращение к DOM методам jQuery будет осуществляться в рамках сервиса, причем только при одном вызове.

$.muAjax ();

и после этого любое обращения к ajax методам jQuery будет осуществляться в рамках сервиса, причем только при одном вызове.
Например:

$.muAjax();
$.get( '/page', function( response ) { alert(response ) } ); // отобразит в alert содержимое со страницы http://[домен сервиса]/page; произошел вызов, следующий, $.get будет обращаться к площадке.
$.get( '/page', function( response ) { alert(response ) } ) // отобразит в алерт содержимое со страницы http://[домен площадки]/page;

Идеи для упрощения процесса правки html/css оформления сервиса интегрированного в площадку нету. Однако, один из простейших, на мой взгляд, это делать в сервисе правильную семантическую верстку, изобилующую, id и/или class атрибутами, чтобы за них потом легко можно было зацепиться. Ну и средствами css править. В этом случае понадобится только работа верстальщика, работа программиста практически не потребуется.

Имеется возможность интегрирования с iframe и без него. Использовать версию с iframe или без зависит от сервиса. С iframe безопаснее, сервис не может выполнить любой js метод площадки, прочитать document.cookie и т.п. Без него — больше свободы, но меньше шансов, что кто-то захочет установить его себе на страницу. Зависит, пожалуй, от авторитетности. Например, многие устанавливают виджеты facebook, но никто особо не думает, что он ( facebook ) когда-нибудь не захочет незаметно обратиться к document.cookie, собрать персональные данные, и потом их каким либо образом использовать в своей логике. Потому что facebook известный, популярный сервис. Частично проблему с безопасностью для версии без iframe площадка может решить исключением небезопасного js кода, проверки на сервере ajax запросов, установкой атрибута httpOnly для важных cookie.

Другие инструменты, полезные при создании мэшапа

Пока есть прототип только аналога iframe, но есть еще нереализованные идеи для решения других вопросов интеграции.

Общая авторизация

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

Доступность сервиса для поисковиков

При необходимости площадка может добавить на серверную часть специальный код, который будет пропускать через себя json ответы сервиса, подменяя ссылки. Версия для поисковика будет работать на ссылках без "#". Но при попадании на такую ссылку клиента, поддерживающего js будет автоматический редирект на страницу с "#".

Виджеты

Чтобы на новый раздел на площадке попали пользователи, может понадобиться возможность вывода блоков со ссылками. Например, на главной странице площадки пригодился бы виджет на новые страницы в сервисе ( Последние посты, комментарии, объявления, товары, события и пр… ). Или виджеты которые на основе контента конкретной страницы покажут наиболее близкие по смыслу ссылки на сервис-раздел. Содержимое виджета генерируется на сервере сервиса. В качестве входящих данных может быть ссылка на страницу, содержимое определенного контейнера, просто какие-то переменные, ключевые слова и т.п.

CPA статистика

Для оценки полезности мэшапа и взаиморасчета между владельцем сервиса и площадки может понадобиться инструемент CPA (Cost per action) статистики. Pазработчик cервиса определяет ключевые действия, а система собирает статистику о их выполнении пользователем.

Как можно использовать

• возможность монетизировать трафик и расширить функционал с помощью внешнего сервиса — раздела без траты времени на организацию интеграции для сайта с большой популярностью;
• понять/проверить пользу/бесполезность приложения сервиса для социальной сети конкретного работающего сайта, с экономией ресурсов разработки;
• после разработки и успешного запуска приложения работающего сайта, возможность с минимальными затратами, встроить в любой другой сайт с высокой посещаемостью;
• распространение сервиса работающего федерального сайта в виде специального раздела на популярных региональных сайтах;
• дополнительный маркетинговый инструмент ( возможность интегрировать свой сервис на другой ресурс ) для уже работающих сайтов;
• сэкономив время и ресурсы на SEO и рекламу, проверить идею в рамках уже работающего сайта с трафиком для стартап-сервиса;
• возможность для стартап-сервиса вообще не создавать свой сайт, и зарабатывать деньги на совместных мешапах с уже популярными раскрученными сайтами;
• для сайтов на конструкторах (ucoz.ru и подобных), возможность добавить на сайт сервис — раздел, который сложно реализуется в рамках движка;
• для highload сайта возможность снизить нагрузку, HTTP трафик, скорость отображения страницы за счет возможности кеширования, обработки и сборки страницы из контента, сгенерированного разными серверами на клиенте;
• для большого сайта или социальной сети как вспомогательный инструмент при организации платформы наподобие тех что уже есть на сайтах facebook.com, vk.com, odnoklassniki.ru, my.mail.ru, позволяющих создавать iframe-приложениия внешним компаниям;
• для внутрикорпоративных веб приложений, собирающих информацию с разных серверов.

Основная идея — предоставить возможность сайту, добившемуся успеха в привлечении трафика, взаимовыгодно сотрудничать с сайтом, способным его (трафик) монетизировать. Согласно исследованию ( 5-я страница ) ^[5] в рунете только 9,9% сайтов монетизируются с помощью сервисной модели. На мой взгляд, возможность легкого взаимовыгодного обмена сервисами между сайтами может поднять эту цифру, и в конечном счете стимулировать развитие новых стартап-сервисов.

Сомнения

1. Есть что-то чего я не знаю или в чем я заблуждаюсь, что делает всю идею бесполезной?
2. iframe и так всем хорош и прост, и много где используется, зачем усложнять?
3. Url в социальном приложении, например, не меняется, не потому что с iframe не позволяет, а просто потому что никому не надо. В интернете практически не нашел большого количества недовольных.
4. Суть проблемы ( а есть ли она вообще? ) нереально описать человеку, который с iframe не работал, или вообще технически неподкованному.
5. Социальные приложения и так делаются — «раз, два, и готово… там же обычный iframe», будет ли экономия времени разработки?

С помощью этой статьи хочу узнать, насколько проект интересен. Получить дополнительную мотивацию для активной разработки, или наоборот, понять, что это никому не надо. Буду рад конструктивной критике.

Автор: kraut