Мне нужно разработать виджет, который будет использоваться сторонним сайтом. Это не приложение для развертывания на сайте социальной сети. Я могу дать ребятам сайта ссылку, которая будет использоваться как src iframe, или я могу разработать ее как запрос JavaScript.
Может кто-нибудь скажет мне компромисс между двумя подходами (IFrame против JS)?
Я искал тот же вопрос, и я нашел эту интересную статью:
http://prettyprint.me/prettyprint.me/2009/05/30/widgets-iframe-vs-inline/
Виджеты - это небольшие веб-приложения, которые можно легко добавить в любую сеть стр. Их иногда называют гаджетами и широко используются в выращивании количество веб-страниц, блоги, социальные сайты, персонализированные домашние страницы, такие как как iGoogle, мой Yahoo, netvibes и т.д. В этом блоге я использую несколько виджеты, такие как счетчик RSS справа, который показывает, сколько пользователи подписываются на этот блог (не беспокойтесь, itll grow, thats a новый блог;-)). Виджеты велики в том смысле, что они маленькие многократно используемая функциональность, которую могут использовать даже не программисты чтобы обогатить их сайт.
Я написал несколько таких виджетов за время, когда оба "сырого" виджетов которые могут быть встроены в любой сайт, а также гаджеты iGoogle, которые более структурированные, захватывающие *, виджеты типа и блога, поэтому Im happy поделиться своим опытом.
Как автор виджета, для виджетов, выполняемых на стороне клиента (простой вложенный HTML-код) у вас есть выбор для написания виджета внутри iframe или просто встроить страницу и сделать ее частью dom страницы хостинга. В остальной части сообщения обсуждаются плюсы и минусы обоих методов.
Как это технически сделано? Как использовать iframe или как реализовать встроенный виджет?
Ифрагмы несколько проще реализовать. Следующий пример создает простой виджет iframe: http://my-great-widget.com/widgwt 'width = "100" height = "100" frameborder = '0' >
frameborder = 0 'используется, чтобы убедиться, что ifrmae не имеет границы поэтому он выглядит более естественным на странице. http://my-great-widget.com/widget отвечает за обслуживание виджета как полную HTML-страницу.
Встроенные гаджеты могут выглядеть так:
function createMyWidgetHtml() {return "Привет, мир виджетов"; } document.getElementById('myWidget'). innerHTML = createMyWidgetHtml(); Как вы видите, функция createMyWidgetHtml() отвечает за создание фактического содержимого виджета и необязательно поговорите с сервером, чтобы сделать это. В примере iframe должно быть сервер. В встроенном примере не обязательно должен быть сервер, хотя в случае необходимости можно получить данные с сервера, на самом деле это очень распространенный случай, виджеты обычно вызывают серверную сторону код. Использование встроенного кода сервера на стороне сервера вызывается с помощью на-demmand javascript.
Итак, чтобы суммировать, в случае iframe мы просто помещаем iframe HTML кода и указать источник iframe в локализованное местоположение, которое фактически служит содержимому виджета. В inline случае мы создайте контент локально с помощью javascript. Конечно, вы можете комбинировать использование iframe с javascript, а также использование встроенного метода с вызовами на стороне сервера, вы не ограничены этим, но пути начните по-разному.
Так в чем же дело? Какая разница? Есть несколько важные отличия, поэтому здесь начинается интересная часть пост.
Безопасность. Виджеты iFrame более безопасны.
Какие риски налагают гаджеты и кто на самом деле подвергается риску? пользователь сайта и репутация сайтов находятся под угрозой.
При использовании встроенных гаджетов браузер считает, что источник гаджета код кода поступает с сайта хостинга. Предположим, что вы просматриваете ваше любимое почтовое приложение http://my-wonderful-email.com и это mail приложение установило виджет, который отображает часы из http://great-clock-widgets.com/. Если эти виджеты реализованы как встроенный виджет, браузер считает, что код виджетов возник из my-wonderful-email.com, а не на great -clock-widgets.com, и поэтому itll пусть код виджетов в конечном итоге получит доступ к файлам cookie, принадлежащим my-wonderful-email.com и злобный автор виджета украдут ваш Эл. адрес. Важно понимать, что браузеры не заботятся о том, где файл javascript размещен; пока код работает на одном и том же кадра, браузер рассматривает весь код как источник g в кадрах домен. Итак, вы, как пользователь, пострадали, потеряв контроль над своей электронной почтой и моя замечательная электронная почта получает больно, теряя свою репутацию.
Если бы такие же часы были реализованы внутри iframe и источник iframe отличается от источника страницы (который является общий случай, например. источником страницы является my-wonderful-email.com и источник гаджета - great-clock-widgets.com), тогда браузер не будет разрешить виджетам часов доступ к файлам cookie страницы и не разрешать доступ к любой другой части хостинг-документа, включая хост page dom. Это намного безопаснее. На самом деле, личный дом такие страницы, как iGoogle, даже не позволяют встроенные гаджеты, только iframe гаджеты разрешены. (встроенные гаджеты разрешены только в редких случаях, только после тщательной проверки командой iGoogle, чтобы убедиться theyre не злонамерен)
Подводя итог, виджеты iframe более безопасны. Однако они также более ограниченный по функциональности. Затем хорошо обсудите, что вы теряете в функциональность.
Взгляд и чувство В взгляде и чувстве битвы встроенные гаджеты (обычно **) выиграть. Самое приятное в том, что их можно заставить выглядеть часть страницы. Они могут наследовать стили CSS со страницы, включая шрифты, цвета, размер текста и т.д. В iframe OTHO должен определить свой CSS из основания, поэтому довольно сложно их хорошо сочетать в стр.
Но еще важнее то, что iframes должны объявить, что их размер будет. При добавлении iframe на страницу вы должны включить свойство ширины и высоты, и если вы не используете его, браузер будет использовать некоторые настройки по умолчанию. Теперь, если ваш виджет - виджет часов, который достаточно легко b/c, вы знаете, какой размер вы хотите, но в многие случаи, которые вы не знаете заранее, сколько места занимает ваш виджет собирается взять. Если, например, вы создаете виджет, который отображает список какого-то рода, и вы не знаете, как долго этот список будет быть или как широкий каждый элемент будет. Обычно в HTML это не большое дело, потому что HTML - это декларативный язык, поэтому все, что вам нужно сделать, это сообщить браузеру, что вы хотите отобразить, и браузеру будет определять разумный макет для него, однако с iframe это это не так; браузеры ifrmaes требуют, чтобы вы точно это указали каков размер iframe, и он сам не поймет это. Эта это настоящая проблема для авторов виджетов, которые хотят использовать iframes - если вы требуют слишком много места, на странице будут пустоты, и если вы укажите слишком мало, чтобы страница имела полосы прокрутки, бог запрещает.
Посмотрите и почувствуйте себя мудрым, inline побеждает. Но обратите внимание, что это действительно зависит от приложение вашего виджета. Если все, что вы хотите сделать, это часы, вы можете получить наряду с iframe так же хорошо.
По отношению к стороне сервера и стороне клиента IFrmaes требуется указать URL-адрес src, чтобы при внедрении виджета с использованием iframe вы должны иметь серверную сторону код. Это может быть как ограничение, так и головная боль для некоторых (владеющая сервер, доменное имя и т.д., занимающееся загрузкой, оплатой счетов в сети и т.д.), но для других это фактически точка в пользу iframes b/c it позволяет полностью писать ваши виджеты в серверных технологиях, поэтому вы можете написать много кода и фактически почти все это, используя ваша любимая технология на стороне сервера, будь то asp.net, django, ror, jsp, struts, perl или других динозавров. При реализации встроенный гаджет, вы все больше и больше javascript Ninja.
Что такое алгоритм решения? Авторы виджета: если виджет может быть реализованы как iframe, предпочитают iframe просто для сохранения безопасности пользователей и доверия. Если виджет требует вложения (и среда позволяет, например, не iGoogle и друзья) используют встроенные, но решаются не используйте доверие пользователей!
Установщики виджета: при установке виджета в своем блоге вы не видите ленту "безопасных для пользователей" на виджетах. Как вы можете сказать, виджет безопасен или нет? Есть две альтернативы, которые я могу предложить: 1) доверять поставщику 2) прочитать код. Либо вы доверяете виджету провайдера и установить его в любом случае, или вы нашли время, чтобы прочитать его код и определить, заслуживает ли это доверия или нет. Реальность что большинство владельцев сайта не беспокоят чтение кода или даже не знают риска, который они ставят своим пользователям, и поэтому поставщики виджета слепо доверяют. Во многих случаях это не проблема, поскольку блоги обычно не содержат личную информацию об их читателях. Я подозреваю вещи начнут меняться, если есть несколько высокопрофильных эксплойтов (и я надеюсь, что он никогда не дойдет до него).
Пользователи: Usres хранятся в темноте. Так же, как нет "безопасного для пользователей", на которых установлены владельцы сайтов виджетов, нет "безопасных использовать" сайты и в основном пользователи хранятся в темноте и понятия не имеют, даже если они обладают техническими навыками, независимо от того, находятся ли они на сайте используются виджеты, независимо от того, являются ли виджеты встроенными или нет; являются ли они злонамеренными. Хотя теоретически обученный разработчик может проверить код вверх, прежде чем запускать его в своем браузере и проиграть ее адрес электронной почты для хакера, однако это не практично, и там не следует ожидать, что пользователи в массовом порядке это сделают. ИМО это неудачное состояние, и я надеюсь, что злоумышленники не найдут способ воспользоваться этим и обречь прекрасную открытую культуру виджетов в Интернете.
Счастливые люди, участвующие в голосовании!
- Некоторые блоговые платформы имеют несколько разные структуры для виджетов, и иногда они могут иметь как виджеты, так и плагины, которые могут коррелируют в их функциональности, но в связи с обсуждением здесь Ill lously использовать термин widget, чтобы обсудить "сырой" тип, который состоит из кода javascript на стороне клиента ** Хотя в большинстве случаев вы хотите, чтобы виджеты наследовали стили на странице хостинга, чтобы они выглядели совместимыми с ним, иногда вы на самом деле не хотят, чтобы виджет наследовал стили со страницы, поэтому в в этом случае iFrames позволяет вам начинать свой CSS с нуля.
Почему бы не обойтись?
Я предпочитаю предлагать сторонние сайты script как:
<script type="text/javascript" src="urlToScript"></script>
файл на вашем сервере выглядит так:
document.writeln('<iframe src="pathToYourGroovyWidget"
name="MagicIframe" width="300" height="600" align="left" scrolling="no"
marginheight="0" marginwidth="0" frameborder="0"></iframe>');
UPDATE:
большой недостаток использования iframe, который указывает на URL-адрес вашего сервера, заключается в том, что вы не генерируете "реальную" обратную ссылку, если кто-то нажимает на URL-адрес вашего сервера, указывая на ваш сервер.
Я уверен, что многие разработчики/владельцы сайтов оценят решение Javascript, которое они могут использовать для своих нужд, а не с помощью iframe. Если бы я собирался включить компонент из третьей стороны, я бы предпочел сделать это с помощью Javascript, потому что у меня было бы больше контроля.
Что касается простоты использования, то они одинаковы по простоте, поэтому нет реального компромисса.
Еще одна мысль: убедитесь, что вы получили сертификат SSL для любого домена, на котором вы размещаете это, и выписываете инструкцию include соответственно, если страница обслуживается через SSL. В случае, если у ваших владельцев сайта есть причина для использования SSL, они, несомненно, оценят это, потому что Firefox и другие браузеры будут жаловаться, когда страница будет обслуживаться с использованием безопасного/небезопасного контента.
Если виджет может быть встроен в iframe, лучше будет работать с интерфейсом хостинг-сайта, так как iframe не блокируют загрузку контента. Однако, как прокомментировали другие, есть и другие недостатки в использовании iframes.
Если вы реализуете в javascript, рассмотрите лучшие методы работы с интерфейсом при разработке. В частности, вы должны посмотреть Не блокировать загрузку javascript. Google Analytics и другие сторонние поставщики виджетов поддерживают этот метод загрузки. Это также поможет, если вы можете загрузить javascript в нижней части страницы.
Приятно знать, что он не будет размещен на сайте социальной сети..., который просто оставит остальную часть Интернета; -)
Что будет полезно, зависит от вашего виджета. IFrames и javascript обычно выполняют совершенно разные цели и могут быть смешаны (т.е. Javascript внутри iframe или javascript, создавая iframe).
Большой плюс iframes: все CSS и JS отделены от главной страницы, поэтому ваш существующий CSS просто работает. (Если вы хотите, чтобы хост-сайт настроил ваш контент в соответствии с этим, это минус, конечно.)
Большой минус iframes: они имеют фиксированную ширину и высоту, а полосы прокрутки появятся, если ваш контент больше.