小部件 - 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的大減號：它們具有固定寬度和高度，並且如果內容較大，則會出現滾動條。