iframe對我的MVC網絡應用程序場景有好處或壞處

我一直在研究Intranet Web解決方案，這些解決方案將由系統的特定用戶組（如供應鏈管理）使用。沒有搜索引擎優化或市場營銷 - 只有易用性和簡單性，吸引他們，使他們的任務簡單。iframe對我的MVC網絡應用程序場景有好處或壞處

我使用MVC2與ASP.Net。我會用通用術語解釋我的情況。我有一個包含標籤視圖的頁面。第一個選項卡從主表加載記錄，其他選項卡加載某些詳細信息表的數據。而理想的例子是這樣的：

表1：添加/編輯客戶（主）記錄

表2：添加/編輯訂單的客戶

標籤3：添加/編輯項爲訂單（取決於標籤2）

標籤4：添加/編輯不同的地址爲客戶

我使用jQuery UI選項卡。現在根據我對iframe的瞭解 - 如果我設計此頁面（視圖）以將第一個選項卡及其內容包含在一個頁面中（View），而其餘選項卡則包含使用單獨頁面（視圖）的iframe。簡而言之 - 所有相關的標籤都會有其獨立的頁面。

的好處我見 -

頁面變得v.light和快速，因爲當用戶正在選項卡上1個其他選項卡將加載他們的iframe中。

在功能上，每個選項卡必須具有自己的添加/編輯和獨立列表。例如，如果我添加地址，那麼只有我的地址iframe將被刷新，並且標籤/頁面的其餘部分不需要回發，並且將重新加載數據。

具有通用保存/取消功能需要在對象層次結構的內存中緩存v.complex ，如果所有內容都在單個頁面（視圖）中。我可以使用用戶控件（即.ascx），但仍然處理在單個動作中的所有內容都像巨大的&複雜。

我不用擔心SEO或書籤或動態維度。相反，我得到的SOC（分離的擔憂），一切都是分佈v.well和主要事情是它變得非常快，因爲回發是分開的。

..這一切如果我使用iframe的:)不過，我並不認爲有很多人喜歡喜歡的I幀： Are iframes a terrible idea?

如果是的話 - 是有一個相當於jQuery的選擇嗎？我希望它具有iframe的好處，至少可以通過url和單獨的回發動態加載內容。我不想創建一個混亂的AJAX blob，它可以處理事情，但使後端同樣複雜。

請讓我知道你的想法 - 我不想知道好/壞 I幀如何，我只是想知道什麼適合我的要求，如果有對iFrame的更好的選擇..我的場景爲。

編輯＃1：我的IFRAME支持的瀏覽器列表 -

http://www.webmaster-resources101.com/articles/view/417/

編輯＃2：我得到的東西，可能是朝着更好的optioninstead的墊腳石iframe -

它的兩個jQuery插件的組合是着名的jQuery標籤插件，另一個是adhoc插件，它可以控制一個con的回發TAINER。

jQuery用戶界面標籤： http://jqueryui.com/demos/tabs/

的jQuery劫持： http://code.google.com/p/jquery-hijack/

能

這項工作？還有其他更好的選擇嗎？

來源

2011-06-21 Hemant Tank

iframe是壞的。總是不好。不好不好不好。只要使用隱藏層，使用部分回發和ajax – Raynos

請不要拘泥於神話 - 如果你說它的不好也會給我一個更好的選擇。隱藏的DIV對於我提到過的iframes的功能來說並不是好事。 –

@HermantTank Iframes不是se迷惑你的問題的HTML答案。 – Raynos

我只好下車這篇文章來完成它 - Alternative for iframes for jQuery ui tabs plugin - with support for postback

我不想要一個完全「JSified」 ajax基礎模型處理，因爲它會在表示層中引入業務對象級別的詳細信息。所以，爲了保持抽象，我最終使用了一個jQuery插件jquery.forms.js，它允許我的表單被Ajax化。與MVC的「局部視圖」概念相結合，我能夠實現一個完整的AJAX回發解決方案（不會使其變得複雜，或者在客戶端將我的模型級別處理作爲knockoutjs，主幹等中的特徵...（他們是偉大的，但我想保持的東西簡單，控制（服務器端））

謝謝。

來源

2012-08-30 14:03:37

如果您可以控制運行應用程序的瀏覽器，則可以使用iframe。

否則，您很快就會遇到瀏覽器兼容性問題。

來源

2011-06-21 07:55:03 bhagyas

如果你不使用它來注入第三方文檔，我仍然會推薦一個iframe你的頁面。 – Raynos

我沒有什麼喜歡的第三方，訪問的一切都是由我建立的。我不必使它成爲商業廣告，或者低至支持IE3等。此外，至少在我找到與iframe相同的東西之前，如果沒有別的東西可以動態加載數據的話。 –

@HermantTank有一件叫做AJAX的小東西。它動態加載數據。 – Raynos

TL; DR

請讓我知道你的想法 - 我不想知道/壞的I幀多麼好，我只是想知道什麼適合我的要求，如果有一個更好的替代iframe ..爲我的場景。

AJAX解決您的客戶端 - 服務器通信問題。有很多客戶端庫使ajax變得非常簡單。例如Backbone與開箱即用的RESTful服務集成在一起。

AJAX的替代品是COMET和WebSockets。

說理透徹

1.頁面變得v.light和快速，因爲當用戶正在使用標籤1其他選項卡將加載它們的iframe中。主頁

如果你想使用你必須等待所有的iframe反正加載onload事件處理程序的

I幀塊的onload。

完全相同的概念適用於按順序加載HTML。我不認爲HTML加載是一個明顯的瓶頸。我無法想象使用iframe可以顯着提高速度。

然而，使用合理的HTML和延遲加載/分頁可能會讓你明顯加快速度。

2.功能上，每個標籤必須有自己的添加/編輯和列表獨立。例如，如果我添加地址，那麼只有我的地址iframe將被刷新，其餘的標籤/頁面不需要回發並重新加載數據。

每個標籤應該有它自己的形式，而不是你可以回發。如果用戶有JavaScript，那麼你使用Ajax。

3.如果所有內容都位於單個頁面（View）中，則具有通用保存/取消功能將需要v.complex在內存中緩存對象層次結構。我可以使用用戶控件（即.ascx），但仍然可以在一個動作中處理所有內容，就像是巨大的複雜的。

編號使用骨幹/脊椎。實現客戶端MVC，它非常簡單，結構良好。

4.我不用擔心SEO或書籤或動態維度。相反，我得到了SOC（關注點分離），所有內容都是分發給v.well的，主要的一點是，由於回傳是分開的，因此它變得非常快。

你仍然發佈回來，而不是使用視覺較慢的ajax。使用適當的HTML5技術，包括客戶端MVC，它將分發得非常好，速度非常快。

缺點：
- 跨iframe的溝通是一個正確的疼痛。
它減慢你的速度，是一種痛苦的發展。您在iframe中的所有內容都很難耦合在一起，因爲它們都與一個客戶有關。

你打算如何處理在主選項卡中更改客戶？您是否要重新加載其他3個iframe以重新填充正確的數據？

這是非常昂貴和緩慢
- 沒有語義
上下文中，這個元素可用於：凡嵌入內容的預期。

您的選項卡不是嵌入式內容。只有普通的HTML表單，它們應該是。
- 缺少跨iframe的代碼重用，因爲每個iframe都有自己的代碼池。
因爲每個iframe都是沙箱，您也不能重複使用元素和全局數據。這意味着擴展第五個選項卡會很麻煩，因爲您必須開發一個全新的選項卡，而不是插入現有的功能。

我相信你的主要問題是不理解，有很多工具可以編寫高質量的javascript應用程序來解決你的問題。

使用backbone或spine或knockoutjs。您可能還需要考慮您所選擇的模板引擎（我會建議EJS或玉）

來源

2011-06-21 15:03:38 Raynos

+1以獲得明確的缺點列表。它只是不能更清楚。 – Sparky

我希望我可以給另一個+1說：_「我相信你的主要問題是不瞭解有很多工具可以編寫高質量的javascript應用程序來解決你的問題。」_ – Sparky

@ Sparky672我不知道認爲這是他本身的問題。我只是相信他正在閱讀大約2000年的文章和以下的教導，並不符合現代技術的數據。 JS是一個快速發展的行業。三年前的景觀截然不同。 – Raynos

iframe對我的MVC網絡應用程序場景有好處或壞處

回答

相關問題