现代的仅限Intranet的Web应用程序是否仍然使用框架?

时间:2010-06-23 17:40:25

标签: web-applications frames

我想询问在现代仅限Intranet的Web应用程序中使用框架。 当然,在现代互联网Web应用程序中使用或可能不使用框架有几个原因。 但是,当涉及到Intranet Web应用程序时(考虑一个财务应用程序)呢?

考虑应用程序中大部分时间不断可见的部分(如工具栏,菜单,标识等),框架可以是一个简单/快速的解决方案吗? 在考虑像PPR这样的事情时,这几天的优势是否很重要?

我很好奇并且都很感谢你对此的看法。

8 个答案:

答案 0 :(得分:13)

框架并非继承邪恶,但它们确实带来了其他方法无法面对的挑战。既然你在谈论内联网,你可能不关心:

  • 框架的搜索索引含义
  • 可用性/可访问性问题
  • 支持显着不同的浏览器(移动,基于文本等)

总的来说,可能没有一个突出的理由来躲避他们。但是我不认为你提供了令人信服的理由 使用它们。

然而:我可以看到你遇到一个 rich 互联网应用程序的问题是你的不同页面/组件可能需要彼此交谈。框架可能是一个带有脚本的皇家头痛,仅仅因为这个原因我就避免使用它们。

答案 1 :(得分:3)

CSS,ASP.NET母版页以及大量其他技术使框架变得不必要,更不用说难看了。

并不是说你不能使用框架,只是你应该避免使用框架,因为它们看起来有点不专业。对我来说,帧与GIF动画处于同一级别。

答案 2 :(得分:2)

我认为在现代Web应用程序中使用框架没有令人信服的理由。当代标记技术即使不是更容易维护,也可以解决一些框架的挫折(你永远不能将任何东西加入书签,很难设置页面标题等)。框架的大多数缺点都可以解决,但为什么要这么麻烦?

答案 3 :(得分:1)

正如其他人所说,框架几乎已成为过去。一个主要的例外是在处理文件时,如果你想要像ajax一样的体验并且有用户上传文件,iframe是唯一的方法(现在)。

答案 4 :(得分:0)

无论如何,框架都令人沮丧。如何使用AJAX刷新您正在更改的页面部分?假设您没有使用IE6。

答案 5 :(得分:0)

框架绝对不能用于工具栏或菜单。当浏览器在页面之间完全匹配时,浏览器会对其进行缓存,使得iframe最多无用,最坏的情况是有害的(双重包含JS库等)。

尽管如此,还是有一些特定的用例需要用于框架。然而,在你遇到它们之前,你不需要它们。

答案 6 :(得分:0)

主没有。内部与否,你为什么要使用框架,它们陈旧而过时,需要死于可怕的死亡。

相反,如果您认为自己无法打破范式,请改用<iframe>

不要误解我的意思,如果你决定使用框架,宇宙不会崩溃,但是标准不再支持它们了,你可能会把IE推入Quirks模式并最终让人头疼。更不用说你最终会让你的用户与上下文对抗并且该网站根本不会是智能手机友好。

答案 7 :(得分:0)

CSS绝对克服了基于框架和表格的布局。 ( - &gt; no)