Tengo que desarrollar un widget que será utilizado por un sitio de terceros. Esta no es una aplicación que se implementará en un sitio de redes sociales. Puedo darle a los chicos del sitio un enlace para usarlo como el src de un iframe o puedo desarrollarlo como una solicitud de JavaScript.Widget - Iframe versus JavaScript
¿Puede alguien decirme las compensaciones entre los 2 enfoques (IFrame versus JS)?
bueno saber que no es para ser desplegado en un sitio de redes sociales ... que simplemente deja el resto de la web ;-)
Lo que sería más útil depende de su widget. IFrames y javascript generalmente tienen propósitos diferentes y se pueden combinar (por ejemplo, javascript dentro de un iframe o javascript creando un iframe).
que estaba buscando sobre la misma pregunta y me encontré con este interesante artículo:
http://prettyprint.me/prettyprint.me/2009/05/30/widgets-iframe-vs-inline/
Los widgets son pequeñas aplicaciones web que se pueden añadir fácilmente a cualquier página web . A veces se llaman Gadgets y se usan ampliamente en el creciente número de páginas web, blogs, sitios sociales, páginas de inicio personalizadas como 0Google, Yahoo, Netvibes, etc. En este blog utilizo varios widgets de , como el contador de RSS. a la derecha que muestra cuántos usuarios de están suscritos a este blog (no se preocupe, crecerá, ese es un nuevo blog ;-)). Los widgets son geniales en el sentido de que son pequeños pieza reutilizable de funcionalidad que incluso los no programadores pueden utilizar para enriquecer su sitio.
He escrito varios de estos reproductores durante el tiempo de ambos widgets “en bruto” que pueden quedar incrustados en cualquier sitio, así como aparatos de iGoogle que son más estructurado, Worpress *, TypePad y Blogger widgets, así que estoy feliz para compartir mi experiencia.
Como autor del widget, para los widgets que se ejecutan en el lado del cliente (simple código HTML embebido) usted tiene la opción de escribir su widget dentro de un iframe o simplemente inline la página y hacerla parte de la dom de la página de alojamiento El resto de la publicación analiza los pros y los contras de ambos métodos.
¿Cómo se hace técnicamente? ¿Cómo usar un iframe o cómo implementar un widget en línea?
Iframes es algo más fácil de implementar.El siguiente ejemplo hace que un simple widget de iframe: http://my-great-widget.com/widgwt 'width = "100" height = "100" frameborder = '0'>
frameborder =' 0 ' se usa para asegurarse de que ifrmae no tenga un borde por lo que se ve más natural en la página. El http://my-great-widget.com/widget es responsable de servir el contenido del widget como una página HTML completa.
aparatos Inline podría tener este aspecto:
función createMyWidgetHtml() {return "Hola mundo de los widgets"; } document.getElementById ('myWidget'). InnerHTML = createMyWidgetHtml(); Como puede ver, la función createMyWidgetHtml() es responsable de creando el contenido del widget real y no necesariamente tiene que hablar con un servidor para hacer eso. En el ejemplo de iframe, debe haber un servidor . En el ejemplo en línea no es necesario que haya un servidor, aunque si es necesario, es posible obtener datos del servidor, que es en realidad un caso muy común, los widgets suelen llamar al lado del servidor . El uso del código del lado del servidor del método en línea se invoca mediante on-demmand javascript.
tanto, para resumir, en el caso de marco flotante que sólo tiene que colocar un código HTML iframe y el punto de la fuente del marco flotante a un lugar Sever, que sirve en realidad el contenido del widget. En el caso en línea, crea el contenido localmente utilizando javascript. Por supuesto, puede combinar el uso de iframe con javascript, así como el uso del método en línea con llamadas del lado del servidor, no está restringido por eso, pero las rutas comienzan diferencialmente.
Entonces, ¿cuál es el problema? ¿Cual es la diferencia? Existen varias diferencias importantes en , por lo que aquí comienza la parte interesante de la publicación .
Seguridad. Los widgets iFrame son más seguros.
¿Qué riesgos imponen los gadgets y quiénes están en riesgo? El usuario del sitio y la reputación del sitio están en riesgo.
Con gadgets en línea, el navegador considera que la fuente del código de código del gadget proviene del sitio de alojamiento. Supongamos que está explorando su aplicación de correo favorita http://my-wonderful-email.com y esta aplicación de correo ha instalado un widget que muestra un reloj de http://great-clock-widgets.com/. Si los widgets se implementan como un widget en línea , el navegador piensa que el código del widget se originó en my-wonderful-email.com y no en great-clock-widgets.com, por lo que dará para que el código del widget finalmente tenga acceso. a las cookies propiedad de my-wonderful-email.com y el malvado autor del widget robará su correo electrónico . Es importante darse cuenta de que a los navegadores no les importa dónde está alojado el archivo javascript ; siempre que el código se ejecute en el mismo marco , el navegador considera todos los códigos como originationg en el dominio del marco. Entonces, usted como usuario se lastima al perder el control de su cuenta de correo electrónico y my-wonderful-email se lastima al perder su reputación.
Si el mismo reloj habría conseguido implementado dentro de un iframe y la fuente iframe es diferente de la fuente de la página (que es el caso común , por ejemplo, la fuente de la página es my-wonderful-email.com y el gadget source es great-clock-widgets.com) entonces el navegador no podría permitir que los widgets del reloj accedan a las cookies de la página, ni permitirá el acceso a a cualquier otra parte del documento de alojamiento, incluyendo la página del host dom. Eso es mucho más seguro. De hecho, las páginas de inicio personal , como iGoogle, ni siquiera permiten gadgets en línea, solo se permiten los artilugios iframe . (Aparatos en línea sólo se permiten en casos raros, sólo después de la inspección a fondo por el equipo de iGoogle para asegurarse de que no son malicioso)
En resumen, los widgets iframe son la forma más segura. Sin embargo, también son mucho más limitadas en funcionalidad. A continuación, analizaremos lo que pierde en la funcionalidad .
Mirar y sentir En el aspecto y la sensación de batalla en línea gadgets (generalmente **) ganar. Lo bueno de ellos es que se puede hacer que se vean como como parte de la página. Pueden heredar estilos CSS de la página, incluidos fuentes, colores, tamaño de texto, etc. Iframes, OTHO debe definir su CSS desde , por lo que es bastante difícil para ellos mezclarse bien en la página .
Pero lo que es aún más importante es que los iframes deben declarar cuál será su tamaño . Al agregar un iframe a una página, debe incluir una propiedad width y height, y si no lo hace, el navegador usará algunas configuraciones predeterminadas. Ahora, si su widget es un widget de reloj que es bastante fácil de usar, puede saber exactamente qué tamaño quiere que sea, pero en muchos casos que no sabe de antemano cuánto espacio va a tomar su widget . Si, por ejemplo, está creando un widget que muestra una lista de algún tipo y no sabe por cuánto tiempo esta lista va a ser o qué ancho de cada elemento va a ser. Por lo general, en HTML esto no es un gran problema porque HTML es un lenguaje basado en declaraciones, por lo que todo lo que necesita es indicarle al navegador lo que desea mostrar y el navegador encontrará un diseño razonable para él, sin embargo con iframe esto no es el caso; con los navegadores ifrmaes exigen que le cuente exactamente cuál es el tamaño del iframe y no lo resolverá por sí mismo. Este es un problema real para los autores de widgets que desean utilizar iframes; si requieren demasiado espacio, la página tendrá vacíos en ella y si especifica muy poco que la página tendrá barras de desplazamiento en ella, dios lo prohíbe.
Luzca y siéntase sabio, gana en línea. Pero tenga en cuenta que esto realmente depende de su aplicación de widgets. Si todo lo que quiere hacer es un reloj, puede obtener junto con un iframe igual de bien.
Lado del servidor frente al lado del cliente Las IFrmaes requieren que especifique una URL src para que al implementar un widget utilizando un iframe debe tener el código del lado del servidor .Esto podría ser una limitación y un dolor de cabeza para algunos (poseer un servidor , nombre de dominio, etc., que se ocupa de la carga, pagar facturas de red, etc.) , pero para otros esto es en realidad un punto a favor de iframes b/c . escriba completamente sus widgets en tecnologías del lado del servidor, para que pueda escribir mucho del código y en realidad casi todo usando su tecnología favorita del lado del servidor ya sea asp.net, django, ror, jsp, struts, perl o otros dinosaurios. Al implementar un gadget en línea , se encontrará practicando cada vez más su javascript Ninja.
¿Cuál es el algoritmo de decisión entonces? Autores de widgets: si el widget puede implementarse como un iframe, prefiera un Iframe simplemente para preservar la seguridad y confianza de los usuarios de . Si un widget requiere enlining (y el medio lo permite, por ejemplo, no iGoogle y sus amigos) use inline pero no se atreva a explotar los usuarios!
Instaladores de widgets: cuando instala un widget en su blog, no ve una cinta de "seguridad para los usuarios" en los widgets. ¿Cómo se puede saber si el widget es seguro o no? Hay dos alternativas que puedo sugerir: 1) confiar en el vendedor 2) leer el código. O confía en el proveedor de widget e instálelo de todos modos o tómese el tiempo para leer su código y determine si es confiable o no. La realidad es que la mayoría de los propietarios de sitios no se molestan en leer el código o ni siquiera son conscientes del riesgo al que están poniendo sus usuarios, por lo que los proveedores de widgets son ciegos. En muchos casos esto no es un problema ya que los blogs no suelen contener información personal sobre sus lectores. Sospecho que las cosas comenzarán a cambiar una vez que haya pocos exploits de alto perfil (y espero que nunca lleguen a eso).
Usuarios: Los usuarios se mantienen a oscuras. Así como no hay "seguros para usuarios", las cintas en los widgets instalados por los propietarios del sitio, no hay sitios "seguros para " y básicamente los usuarios no tienen ni idea, aunque tengan las habilidades técnicas, si el sitio que usan está usando contiene widgets, si los widgets están en línea o no y si son maliciosos. Aunque en teoría un desarrollador capacitado puede inspeccionar el código por adelantado, antes de ejecutarlo en su navegador y perder su cuenta de correo electrónico a un pirata informático, sin embargo, esto no es práctico y no debe esperar que los usuarios en masa lo hagan . IMO esto es una condición desafortunada y solo espero que los atacantes no encuentren una manera de aprovechar eso y condenar la maravillosa cultura de widget abierta en la web.
¡Gente feliz de widgeting!
- Algunas plataformas de blogs tienen un tanto diferentes estructuras para los widgets y pueden a veces tener ambos widgets y plugins que pueden correlacionar en su funcionalidad, pero por el asunto de la discusión aquí voy a utilizar el widget lously plazo para discutir el tipo "crudo" que consiste en el código de javascript del lado del cliente ** Aunque en la mayoría de los casos desea que los widgets hereden estilos de la página de alojamiento para que se vean consistentes, a veces en realidad no desea el widget para heredar estilos de la página, por lo que en este caso iFrames le permite iniciar su CSS desde cero.
Estoy seguro que muchos desarrolladores/propietarios del sitio apreciarían una solución Javascript que puede estilo a sus necesidades en lugar de utilizar un iframe. Si iba a incluir un componente de un tercero, preferiría hacerlo a través de Javascript porque tendría más control.
En cuanto a la facilidad de uso, ambos son similares en simplicidad, por lo que no hay una compensación real allí.
Otra idea, asegúrese de obtener un certificado SSL para cualquier dominio en el que esté hospedado y escriba la declaración include en consecuencia si la página se sirve a través de SSL. En caso de que los propietarios de su sitio tengan una razón para usar SSL, seguramente apreciarían esto, porque Firefox y otros navegadores se quejarán cuando una página se publique con una combinación de contenido seguro/inseguro.
Si el widget se puede incrustar en un iframe, será mejor para el rendimiento de la interfaz del sitio de alojamiento, ya que los iframes no bloquean la descarga de contenido. Sin embargo, como otros han comentado, existen otros inconvenientes en el uso de iframes.
Si implementas en javascript, considera frontend performance best practices al desarrollar. En particular, debe mirar Non blocking javascript loading. Google Analytics y otros proveedores de widgets de terceros admiten este método de carga. También sería útil si puedes cargar el javascript en la parte inferior de la página.
¿Por qué no hacer las dos cosas?
prefiero intentar ofrecer a sitios de terceros un guión como:
<script type="text/javascript" src="urlToScript"></script>
el archivo en el servidor se ve así:
document.writeln('<iframe src="pathToYourGroovyWidget"
name="MagicIframe" width="300" height="600" align="left" scrolling="no"
marginheight="0" marginwidth="0" frameborder="0"></iframe>');
ACTUALIZACIÓN:
la gran desventaja de utilizar un iframe que apunta a una url en su servidor es que no genera un vínculo de retroceso "real" si alguien hace clic en una URL de su servidor que apunta a su servidor.
La gran ventaja de los iframes: todos los CSS y JS están separados de la página de host, por lo que su CSS existente simplemente funciona. (Si desea que el sitio host califique su contenido, eso es un menos, por supuesto.)
El gran inconveniente de los iframes: tienen un ancho y una altura fijos y aparecerán barras de desplazamiento si su contenido es más grande .
Otro beneficio que pude ver al usar un iFrame sobre JavaScript es que cualquier CSS o Javascript que requiera sería independiente y no interferiría con el sitio web llamante. Por supuesto, puede evitar esto fácilmente mediante el uso de selectores no genéricos. – Noz
en un iframe, puede usar SLL; en javascript, el sitio web principal debe tener ssl instalado. –