小部件 – Iframe与JavaScript
我必须开发一个将由第三方网站使用的小部件。 这不是要在社交网站上部署的应用程序。 我可以给网站的人一个链接，作为一个iframe的src，或者我可以开发它作为一个JavaScript的请求。
有人可以告诉我两种方法（IFrame与JS）之间的权衡？
我正在寻找相同的问题，我发现这个有趣的文章：
http://prettyprint.me/prettyprint.me/2009/05/30/widgets-iframe-vs-inline/
小部件是可以轻松添加到任何网页的小型Web应用程序。 他们有时被称为小工具，并广泛用于越来越多的网页，博客，社交网站，个性化的主页，如iGoogle，我的雅虎，netvibes等。在这个博客中，我使用了几个小部件，如右侧的RSS计数器其中显示有多less用户订阅了这个博客（不用担心，它会增长，这是一个新的博客;-)）。 从小部件的function来看，小部件非常棒，即使是非程序员也可以利用它来丰富站点。
我已经写了几个这样的小部件，既可以embedded到任何网站的“原始”小部件，也可以embedded到更具结构化的iGoogle小工具，worpress *，键盘和博客小部件，所以我很高兴分享我的经验。
作为一个小部件作者，对于在客户端运行的小部件（简单的可embedded的HTML代码），您可以select在iframe中编写您的小部件，或者简单地将页面内联，并使其成为托pipe页面的一部分。 这篇文章的其余部分讨论了这两种方法的优缺点。
它是如何在技术上完成的？ 如何使用iframe或如何实现内联小部件？
Iframes实现起来更容易一些。 以下示例呈现一个简单的iframe小部件：http://my-great-widget.com/widgwt'width =“100”height =“100”frameborder ='0'>
frameborder ='0'用于确保ifrmae没有边框，因此在页面上看起来更自然。 http://my-great-widget.com/widget负责将小部件内容作为完整的HTML页面提供。;
内联小工具可能如下所示：
函数createMyWidgetHtml（）{返回“小部件世界”; } document.getElementById（'myWidget'）。innerHTML = createMyWidgetHtml（）; 正如你所看到的，createMyWidgetHtml（）函数负责创build实际的窗口小部件内容，并不一定要与服务器通信。 在iframe示例中，必须有一个服务器。 在内联示例中，不需要是服务器，但是如果需要的话，可以从服务器获取数据，这实际上是非常常见的情况，小部件通常会调用服务器端代码。 使用内置方法服务器端代码是通过使用on-demmand javascript来调用的。
因此，总结一下，在iframe的情况下，我们只需放置一个iframe HTML代码，并将iframe的源代码指向实际服务于小部件内容的服务器位置。 在内联的情况下，我们使用javascript在本地创build内容。 你当然可以结合iframe和javascript的使用，以及使用内联方法与服务器端调用，你不受限制，但path启动差异。
那么最重要的是什么？ 有什么不同？ 有几个重要的区别，所以这里开始了这篇文章的有趣的部分。
安全。 iFrame小部件更安全。
小工具施加什么风险，谁实际上处于危险之中？ 该网站的用户和该网站的声誉有风险。
使用内联小工具，浏览器认为小工具代码的源代码来自托pipe站点。 假设您正在浏览您最喜欢的邮件应用程序http://my-wonderful-email.com，并且此邮件应用程序已经安装了一个显示http://great-clock-widgets.com/中的时钟的小部件。; 如果这个小部件是作为内联小部件实现的，那么浏览器会认为这个小部件的代码来源于my-wonderful-email.com，而不是在great-clock-widgets.com，所以它会让小部件的代码最终访问cookie拥有my-wonderful-email.com和小部件的邪恶作者将窃取您的电子邮件。 意识到浏览器不关心JavaScript文件托pipe的位置很重要， 只要代码在同一个框架上运行，浏览器就会将所有代码视为在框架的域中始发。 所以，你作为一个用户受到失去对你的电子邮件帐户的控制而受到伤害，而我的精彩电子邮件受到失去声誉的伤害。
如果相同的时钟已经在iframe中实现，并且iframe源与页面源不同（这是常见的情况，例如，页面源是my-wonderful-email.com，并且小工具源是伟大的时钟小部件.com），那么浏览器将不允许时钟小部件访问页面cookie，也不允许访问托pipe文档的任何其他部分，包括主机页面dom。 这样更安全 事实上，个人主页（如iGoogle）甚至不允许内联小工具，只允许使用内联框架小工具。 （只有在极less数情况下才允许使用内嵌小工具，只有iGoogle小组仔细检查以确保它们不是恶意的）
总而言之，iframe小部件更安全。 但是，它们在function方面也受到更多的限制。 接下来我们将讨论你在function上失去了什么。
外观和感觉在外观和感觉战内联小工具（通常是**）胜利。 关于他们的好处是他们可以被看作是页面的一部分。 他们可以从页面inheritanceCSS样式，包括字体，颜色，文本大小等Iframes，OTHO必须从原理上定义他们的CSS，所以它们很难在页面中很好地融合。
但是更重要的是iframes必须声明它们的大小。 向页面添加iframe时，必须包含宽度和高度属性，如果不包含，则浏览器将使用一些默认设置。 现在，如果你的小部件是一个时钟小部件，它很容易就可以知道你想要的大小，但是在很多情况下，你并不知道你的小部件需要多less空间。 例如，如果您正在创build一个显示某种列表的小部件，而且您不知道这个列表将会多久，或者每个项目将会有多宽。 通常在HTML中，这不是什么大问题，因为HTML是一种基于声明的语言，所以你只需要告诉浏览器你想要显示的内容，浏览器会找出一个合理的布局，但是iframe不是这个案件; 与ifrmaes浏览器要求，你告诉它到底是什么的iframe大小，它不会自行解决它。 对于想要使用iframe的小部件作者来说，这是一个真正的问题 – 如果你需要太多的空间，页面将会有空白，如果你指定的页面太less，页面将会有滚动条，上帝禁止。
外观和感觉明智，内联胜利。 但请注意，这实际上取决于您的小部件应用程序。 如果你想要做的只是一个时钟，那么你也可以和iframe相处得很好。
服务器端与客户端IFCF需要你指定一个src URL，所以当使用iframe实现一个小部件时，你必须有服务器端代码。 这可能是一个（有一个服务器，域名等，处理负载，支付networking账单等）的限制和头痛，但对其他人来说，这实际上是一个有利于iframes b / c它的点它让你完全写你的在服务器端技术的小部件，所以你可以写很多的代码，实际上几乎所有的它使用你最喜欢的服务器端技术，无论是asp.net，django，ror，jsp，struts，perl或其他恐龙。 当实现一个内联小工具，你会发现自己越来越多的练习你的JavaScript忍者。
什么是决定algorithm呢？ 小部件作者：如果小部件可以作为一个iframe来实现，只需要一个iframe来保存用户的安全和信任。 如果一个小部件需要内联（而媒体允许，例如不是iGoogle和朋友）使用内联，但不敢剥削用户的信任！
小工具安装程序：在您的博客中安装小工具时，您不会在小工具上看到“用户安全”function区。 你怎么知道小部件是否安全？ 我可以build议两种select：1）信任供应商2）阅读代码。 要么你信任小部件提供程序并安装它，要么花时间阅读它的代码，并确定它是否值得信赖。 实际情况是，大多数网站所有者不会打扰阅读代码，或者甚至没有意识到他们将用户置于其中的风险，所以小工具提供者是盲目的信任。 在许多情况下，这不是一个问题，因为博客通常不会保存读者的个人信息。 我怀疑一旦有less量高调的漏洞，事情就会开始发生变化（我希望它永远不会实现）。
用户：乌斯雷斯在黑暗中。 正如网站所有者安装的小部件上没有“安全的用户”丝带一样，没有“安全使用”的网站，基本上用户一直在黑暗中，不知道，即使他们有技术技能，不pipe是否他们正在使用的网站包含小部件，小部件是否内联以及是否是恶意的。 尽pipe从理论上说，一个训练有素的开发人员可以预先检查代码，然后在浏览器中运行代码并将其电子邮件帐户丢给黑客，但这不切实际，不应该期望用户能够做到这一点。 国际海事组织这是一个不幸的情况，我只希望攻击者不会find利用这一优势的方式，并在networking上打开美妙的开放小部件文化。
快乐widgeting乡亲！
- 有些博客平台对于小部件有不同的结构，有时可能同时具有可能与其function相关的小部件和插件，但对于这里的讨论，我将使用术语小部件来讨论“原始”types由客户端JavaScript代码组成**虽然在大多数情况下，您希望小部件从宿主页面inheritance样式以使它们看起来一致，有时您实际上不希望小部件从页面inheritance样式，所以在这种情况下iFrames让你从头开始你的CSS。
为什么不做这两个？
我更愿意为第三方网站提供如下脚本：
<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>');
更新：
使用指向服务器上的url的iframe的一大缺点是，如果有人点击服务器上指向服务器的URL，则不会生成“真实”反向链接。
我敢肯定，许多开发人员/网站所有者将欣赏一个JavaScript解决scheme，他们可以风格满足他们的需求，而不是使用iframe 。 如果我要包含来自第三方的组件，我宁愿通过Javascript来做，因为我会有更多的控制权。
就易用性而言，两者在简单性上都是相似的，所以在那里没有真正的折衷。
另一个想法是，确保你获得一个SSL证书，无论你在哪个域名上进行，并且在页面通过SSL提供的情况下，相应地写出include语句。 如果您的网站所有者有使用SSL的理由，他们肯定会感激这一点，因为Firefox和其他浏览器会抱怨，当一个网页是混合安全/不安全的内容。
如果小部件可以embedded到iframe中，则由于iframe不会阻止内容下载，所以对于托pipe站点的前端性能会更好。 但是，正如其他人所评论的那样，使用iframe还有其他缺陷。
如果您使用JavaScript实现，请在开发时考虑前端性能最佳实践 。 特别是，你应该看看非阻塞的JavaScript加载 。 谷歌分析和其他第三方小工具提供者支持这种加载方法。 这也可以帮助，如果你可以加载在页面底部的JavaScript。
很高兴知道这不是被部署在社交网站…只是离开了其余的networking;-)
什么是最有用的取决于你的小部件。 IFrame和JavaScript通常用于完全不同的目的，并且可以混合使用（例如，iframe中的javascript或者创buildiframe的javascript）。
- IFrames有大小问题; 如果它应该是一个确切的适合页面，你知道它在所有的浏览器呈现相同，数据不会溢出它的容器等？
- IFrame很简单。 他们可以是一个简单的，静态的HTML页面。
- 当使用IFrames，你很容易地暴露你的小部件。
- 但是，再次，为什么不让你的第三方网站只包含HMTL在给定的url？ 如果需要，HTML可以扩展为包含javascript。
- 纯Javascript允许更多的灵活性，但代价是一些复杂性。
iframe的大优点：所有的CSS和JS都与主机页面分离，所以你现有的CSS就可以工作了。 （如果你希望主持人的网站适合你的内容，那当然是负面的。）
iframe的大减：他们有一个固定的宽度和高度，滚动条会出现，如果你的内容较大。
