小部件 - Iframe与JavaScript

Question

我必须开发一个小部件，供第三方站点使用。这不是要部署在社交网站上的应用程序。我可以给站点人员一个链接，用作iframe的src，或者我可以将其作为JavaScript请求进行开发。

有人可以告诉我两种方法（IFrame与JS）之间的权衡？

Answer 1

很高兴知道，这不是在社交网站中部署......这仅仅是离开网页;-)

什么是最有用取决于你的部件的其余部分。 IFrames和JavaScript通常用于完全不同的目的，并且可以混合使用（例如，iframe中的javascript或创建iframe的javascript）。

• IFrames sizing issues;如果它应该与页面精确匹配，你知道它在所有浏览器上呈现相同，数据不会溢出它的容器等吗？
• IFrames很简单。它们可以是一个简单的静态HTML页面。
• 当使用IFrames时，你很容易明白你的小部件。
• 但是再一次，为什么不让你的第三方网站只包含在给定的URL的HMTL？如果需要，HTML可以扩展为包含javascript。
• 纯Javascript允许更多的灵活性，但代价有一些复杂性。

Answer 2

我正在寻找关于同样的问题，我发现这个有趣的文章：
http://prettyprint.me/prettyprint.me/2009/05/30/widgets-iframe-vs-inline/

Widget是可以很容易地添加到任何网页 页面小型Web应用程序。他们有时被称为小工具，并广泛用于增长 数量的网页，博客，社交网站，个人主页如 作为iGoogle，我的雅虎，netvibes等在这个博客我使用几个 部件，如RSS计数器在右边显示有多少 用户订阅了这个博客（不用担心，它会增长，这是一个 新博客;-)）。小部件非常棒，因为它们很小，即使非程序员也可以使用 来丰富其网站。

我在一次写几个这样的小部件既“原始”的小部件 可以得到嵌入任何网站，以及iGoogle小工具，其是 更有条理，worpress *，TypePad等和Blogger窗口小部件，所以我开心 分享我的经验。

作为widget作者，该客户端上运行（简单 嵌入HTML代码），你必须写你的widget iframe内或只以内嵌的页面，并使其的DOM 的一部分的选择部件托管页面。这篇文章的其余部分讨论了这两种方法的优缺点 。

它是如何在技术上完成的？如何使用iframe或如何实现内联小部件？

内联框架实现起来有点容易。下面的示例 呈现一个简单的iframe插件：http://my-great-widget.com/widgwt '宽度= “100” HEIGHT = “100” FRAMEBORDER = '0'>

FRAMEBORDER =' 0'是用来确保炎炎没有边界 所以它看起来更自然的页面上。 http://my-great-widget.com/widget负责为小部件 提供内容作为完整的HTML页面。

内嵌小工具可能是这样的：

功能createMyWidgetHtml（）{回报 “你好小部件的世界”; } document.getElementById（'myWidget'）。innerHTML = createMyWidgetHtml（）; 如您所见，函数createMyWidgetHtml（）负责创建实际的窗口小部件内容，并且不一定要 与服务器通信。在iframe示例中，必须有一个 服务器。在内联示例中，不需要是服务器，尽管如果需要，可以从服务器获取数据，其中 实际上是非常常见的情况，小部件通常会调用服务器端 代码。使用内联方法服务器端代码通过 on-demmand javascript进行调用。总而言之，在iframe的情况下，我们只需放置一个iframe HTML 代码，并将iframe的来源指向服务器位置，其中 实际上为小部件的内容提供服务。在内联情况下，我们使用JavaScript在本地创建内容 。你当然可以结合 iframe与javascript的使用，以及使用内联方法 与服务器端调用，你不受限制，但路径 开始差异。

那么最重要的是什么？有什么不同？有几个 重要的区别，所以这里开始 职位的有趣的部分。

安全。 iFrame小部件更安全。

小工具会施加什么风险，谁实际上处于风险之中？该网站的用户和该网站的声誉受到威胁。

使用内嵌小工具，浏览器认为小工具 的源代码来自托管网站。假设您正在浏览 您最喜欢的邮件应用程序http://my-wonderful-email.com，而此 邮件应用程序已安装了一个显示时钟的窗口小部件，其显示的时间为 http://great-clock-widgets.com/。如果该小部件被实现为 内联小部件，则浏览器认为小部件的代码起源于 my-wonderful-email.com，而不是在greatclock-widgets.com，因此它会让 让小部件的代码最终获得访问权限到 my-wonderful-email.com所拥有的Cookie，并且该小部件的邪恶作者将窃取您的 电子邮件。意识到浏览器不关心JavaScript文件的托管位置很重要;只要代码在相同的 框架上运行，浏览器就会将所有代码视为框架的 域的原始代码。所以，作为用户而受到损害的是，您失去了对您的电子邮件帐户的控制权，并且我的精彩电子邮件因失去其声誉而受到伤害。

如果相同的时钟会得到一个iframe和 的IFRAME源内部实现是从页源（其是 常见的情况，例如在网页源是my-wonderful-email.com和 小工具不同源是great-clock-widgets.com），那么浏览器不会允许时钟小部件访问页面cookie，也不会允许 访问托管文档的任何其他部分，包括主机 page dom。这样更安全。事实上，像iGoogle这样的个人主页 甚至不允许内联小工具，只允许iframe 小工具被允许。 （内嵌小工具只允许在罕见的情况下，通过iGoogle团队 后才彻底的检查，以确保 他们不是恶意的）

综上所述，iframe的小部件的方式更为安全。但是，它们也是功能更受限制的方式。接下来我们将讨论您在 功能中丢失的内容。

外观和感觉在外观和感觉战内联小工具（通常**） 胜利。关于他们的好处是，他们可以看起来像 页面的一部分。他们可以从页面继承CSS样式，包括 字体，颜色，文字大小等。Iframes，OTHO必须从 开始定义它们的CSS，因此很难将它们很好地融合在 页面中。

但更重要的是，iframes必须声明他们的尺寸将会是什么。将iframe添加到页面时，必须包含 的宽度和高度属性，如果不包含，则浏览器将使用 某些默认设置。现在，如果你的小部件是一个时钟小部件，那么它很容易就可以知道你想要的大小，但在 很多情况下，你事先并不知道你的小部件需要多少空间 。例如，如果您正在创建一个显示某个列表的 的小部件，并且您不知道此列表将会在多长时间内显示为 或每个项目的宽度有多大。通常在HTML中这不是 大事，因为HTML是一种基于声明的语言，因此您只需要 就可以告诉浏览器您想要显示的内容，而浏览器 将会找出合理的布局，但是通过iframe 并非如此;与ifrmaes浏览器要求，你确切地告诉它 iframe的大小是什么，它不会自己搞清楚。这个 对于想要使用iframe的小部件作者来说是一个真正的问题 - 如果你需要太多的空间，页面会有空白，并且如果你指定的页面太少，那么页面将会有滚动条，上帝不允许。

外观和感觉明智，内联胜。但请注意，这确实取决于您的窗口小部件应用程序的 。如果你想要做的只是一个时钟，那么你也可以得到 以及一个iframe。

服务器端与客户端IFrmaes要求您指定src URL，以便在使用iframe实现窗口小部件时使用 ，您必须具有服务器端 代码。这可能是一个限制和一些头痛（拥有一个 服务器，域名等，处理负载，支付网络账单等） 但其他人这实际上是赞成iframes B/C它 让你在服务器端技术中完全编写您的小部件，因此您可以使用您最喜爱的服务器端技术编写大量代码，实际上几乎所有代码都可以使用，无论是asp.net，django， ror，jsp，struts，perl还是其他恐龙。在实施 内联小工具时，您会发现自己越来越多地练习了您的 javascript忍者。

什么是决策算法呢？小部件作者：如果小部件可以将 实现为iframe，那么首选iframe仅仅是为了保护用户的安全性和信任。如果一个小部件需要内联（并且 介质允许，例如不是iGoogle和朋友）使用内联，但是敢于 不利用用户信任！

小工具安装程序：在博客中安装小工具时，您看不到 小工具上的“用户安全”功能区。你怎么知道 部件是否安全？我可以建议两种选择：1） 相信供应商2）阅读代码。要么您信任提供商的小部件 ，并且无论如何都要安装它，或者您花时间阅读其代码 ，并确定它是否值得信赖。现实是 ，大多数网站所有者不会打扰阅读代码或甚至不知道他们将其用户置于其中的风险 ，因此小工具提供商 是盲目信任的。在很多情况下，这不是问题，因为博客 通常不会保存有关其读者的个人信息。我怀疑 一旦有少量高调漏洞 （我希望它永远不会达到它），事情会开始改变。

用户：Usres被关在黑暗中。就像没有“安全的 用户”小工具网站所有者安装的丝带一样，没有“安全到 使用”的网站，基本上用户都在黑暗中不知情，即使他们有技术技能，无论他们 正在使用的网站是否包含窗口小部件，窗口小部件是否内联，以及它们是否是恶意的都是 。虽然从理论上讲，经过培训的开发人员可以在其浏览器中运行代码之前对其代码进行检查，并将其电子邮件帐户丢失给黑客，但这不实用，并且不应该有用户群体会这样做的期望。国际海事组织这是 一个不幸的状况，我只希望攻击者不会找到一种方式 利用这一点，厄运在网络上的美妙的开放部件文化 。

快乐的插件人！

• 一些博客平台有小部件略有不同的结构，它们有时可能会同时拥有部件和插件，可以在 它们的功能相关，但对于讨论 这里的事情，我会lously使用术语部件讨论“原始”类型 由客户端JavaScript代码 组成虽然在大多数情况下，您希望小部件从宿主页面继承样式以使它们看起来一致，但有时候您实际上并不想要该小部件从页面继承样式，因此在 这种情况下，iFrame允许您从头开始您的CSS。

Answer 3

我相信很多开发商/网站所有者会喜欢一个JavaScript的解决方案，他们可以风格，以他们的需求，而不是使用iframe。如果我要包含来自第三方的组件，我宁愿通过Javascript来做，因为我会有更多的控制权。

就易用性而言，两者在简单性上都很相似，所以没有真正的折衷。

另外一个想法是，确保您获得所有域名的SSL证书，并在页面通过SSL提供时相应地写出include语句。如果您的网站所有者有使用SSL的理由，他们肯定会理解这一点，因为当一个页面混合了安全/不安全的内容时，Firefox和其他浏览器会投诉。

Answer 4

如果小部件可以嵌入到iframe中，那么对于托管站点的前端性能会更好，因为iframe不会阻止内容下载。但是，正如其他人所评论的那样，使用iframe还存在其他缺陷。

如果你在javascript中实现，请在开发时考虑frontend performance best practices。特别是，你应该看看Non blocking javascript loading。谷歌分析和其他第三方小部件提供商支持这种加载方法。如果您可以在页面底部加载JavaScript，它也会有所帮助。

Answer 5

为什么不这样做？

我更愿意提供第三方网站类似的脚本：

<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的大缺点指向您的服务器上的网址是，如果有人点击指向您服务器的服务器上的网址，则不会生成“真实”反向链接。

Answer 6

iframes的大优点：所有的CSS和JS都与主机页面分开，所以你现有的CSS就可以工作。 （如果您希望主机网站适合您的内容的样式，那当然是负数。）

iframe的大减号：它们具有固定宽度和高度，并且如果内容较大，则会出现滚动条。