论坛首页 Web前端技术论坛

One Page, One Application的讨论

浏览 17492 次
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
作者 正文
   发表时间:2005-12-29  
在Michael Chen blog看到一篇blog,引出了一个很有意思的AJAX话题:One Page, One Application,请看:

http://michael.nona.name/archives/117

引用
一 定义

One Page, One Application(后面缩写为OPOA,或者1P1A),含义很简单:一个页面就是一个应用。在众多的基于Web的MIS系统中,没有人关心页面的组织形式;大多数稍微复杂的MIS系统,都采用分祯 (Frame)的方式来组织页面,这样,在进行业务操作的时候,url的变化表现在一个框架页面内,从浏览器的地址看起来,只有一个地址;更有甚者,一些应用干脆弹出一个去掉了浏览器菜单、工具条、地址栏、状态栏的窗口(比如招商银行、民生银行的网上银行系统),连地址都看不见。因此,一个页面就是一个应用,从用户的角度来说,对于操作型系统,是一种非常自然的体现。用户无需了解每一个具体的操作对应的地址是什么。

这种设计背后的含义实际是:是希望由程序来控制用户的行为,还是反过来。在操作型系统中,每一步的操作往往被业务含义严格定义,无论是应用的设计者,还是其使用者,都希望在一种受控的状况下来进行操作。例如,一个审批动作,用户更希望是通过一个按钮来触发,而不是访问类似于 /approve.action?itemid=123的方式。

二 场景

显然,OPOA的设计只能针对那些对URL不敏感的系统,或者说操作型系统。绝大多数MIS系统都属于这一范畴,Email系统也是这一范畴,其他领域,如监控系统,聊天室等都可以采用这种思路。反面的例子是,对于内容型系统,如新闻系统,Blog系统,论坛系统,用户更希望能够通过一个明确的 URL来定位页面内容,搜索引擎也喜欢这种地址。这种应用需要的是一个合理,易懂,明确的地址。

三 设计与实现

大多数MIS系统,无论是有意识或者无意识,都遵循了OPOA的思路。要么采用框架,要么采用弹出窗口来屏蔽URL的直接访问。实现上也很简单,这里就不再赘述了。注意到上述的OPOA地实现只是对用户而言,看起来好像是一个页面一样,但实际上还是有众多的action, page在后面工作。

下面我要说的一种实现是,采用AMOWA/AJAX技术来实现真正意义上的OPOA. 简而言之:主页面(或者称布局页面)只加载一次,其他的操作页面通过AMOWA/AJAX技术来加载,并将其中的操作脚本与布局内容分开,最后进行展示。这个设计的原型在buffalo-1.1dr版本中。细心的开发者一定能注意到,在切换不同demo的时候,只是调用了一个switchPage函数,将不同的页面进行读取并显示。demo的演示速度相当快,因为每次只读取一小部分页面;如果加上缓存机制,将页面进行缓存,那么更快了。

首先存在一个布局页面,这个页面定义了一个应用大致的外观,(例如,大部分MIS系统按照上中下三栏,中间部分左右两栏分别为顶部logo, 操作菜单,具体操作内容,底部状态栏)。用你喜欢的网页编辑工具,将这个页面设计美观,然后按照应用的要求,将页面进行拆分。此时的拆分不用Frame 了,只需要在不同的部位加上<div id=”…”>就可以。

然后在主页面定义一个函数,例如switchPage, 将这个函数使用在需要进行页面切换的地方。在buffalo的sample中,switchPage函数这样实现:

function switchPage(page) {
    pageBuffalo.remoteCall("pageService.loadPage", [page], function(reply) {
        var pageObj = reply.getResult();
        Buffalo.getElementById("body").innerHTML = pageObj.html;
        if (pageObj.script != null || pageObj.script != "") {
            execScript(pageObj.script);
        }
    });
}

你可以用任意你喜欢的AJAX/Amowa引擎来做这件事情。

剩下的工作都可以想象了。你可以将web应用的网页资源全部用html编写,并放在一个不为人知的地方,而通过pageService来读取他们;你可以任意组织你的应用外观,更加自如的切换他们。应用的URL地址永远只有真正的一个,你的应用也要比别人快很多,因为只加载那么一小块内容。

四 小结

AJAX/AMOWA的兴起为我们开阔了很多视野。比起原来的web框架,这种OPOA的方式能够更快,减少更多的编码量,并提供更好的用户体验。当然,上文中提出的只是一个原型实现,如果尝试自行实现,可能更多的东西需要考虑,如安全,缓存,事件回调机制,内存管理等等。但这将是一个方向,一个可以提高开发体验与用户体验的方向。
   发表时间:2005-12-29  
用DELPHI/PB/VB开发过MIS应用的开发人员,当他们转向Web开发时,比较习惯OPOA方式,本人就是。我用ASP.NET和ECHO开发过这样的内网MIS应用。

不过,我现在在开发内容型Web应用,自然非常在意URL。希望AJAX能够提高用户体验,但不能使用OPOA这样的形式。

OPOA可以用作后台管理系统。

Michael Chen 在这篇Blog后面补充说:在buffalo的发展规划中,基于OPOA原则的页面框架将作为重要组成部分被加入。

看来Michael Chen 比较看好OPOA。
0 请登录后投票
   发表时间:2005-12-29  
1p1a这样的应用方式很适合有“程序感”的应用。

比如,类似于office界面的 numsum ,在这样的界面中,给用户的体验是正在用一个“应用程序”。这就好比,在office中,你是不会觉得有使用bookmark或者back/foward按钮的必要。

另外一些应用,比如,ajax增强的标准web,或带ajax widgets的web页面,给用户的体验是,仍然是web,多了一些交互而已,这种情况下page flow仍然是需要关注的问题。

据说dojo的新版提供了对于history的控制功能,可以back到某个“中介过程页面”,dojo的理由是“back/foward是用户对于应用的自由”,但我个人觉得这意义不大。比如,点击tree节点展开,或者drag&drop一个条目,这类动作要怎么back?

我更倾向于以ajax的界面流转方式来代替现有简陋的面向document的history和back/foward的page flow控制方式,也就是说,以1p1a控制之下的界面转换来替代现有的用户自由的back/foward/history方式。
0 请登录后投票
   发表时间:2005-12-29  
我个人也是喜欢opoa这种方式的,尤其是在WEB发展如此迅猛的今天,人们需要的不是html page,而是web application,既然是application,那么opoa是最符合人们习惯的,也是用户体验最好的。

参考一下google ig和windows live,就不难发现opoa的web application是未来web应用的趋势。

http://www.google.com/ig
http://www.live.com
0 请登录后投票
   发表时间:2006-01-24  
OPOA的用户体验感觉更好。这正是目前web GUI向传统Windows GUI的一个有益的借鉴。
0 请登录后投票
   发表时间:2006-02-28  
Flex应该就是应用这种方式的。
0 请登录后投票
   发表时间:2006-03-02  
是 One Page, One Application ? 还是 One Page,One Form (类似传统桌面应用的窗体)?
0 请登录后投票
   发表时间:2006-03-02  
wch3116 写道
是 One Page, One Application ? 还是 One Page,One Form (类似传统桌面应用的窗体)?

就是 One Page, One Application
对这个概念不熟悉的话可以去看一下
ajax in action的第一章
0 请登录后投票
   发表时间:2006-03-02  
box 写道
wch3116 写道
是 One Page, One Application ? 还是 One Page,One Form (类似传统桌面应用的窗体)?

就是 One Page, One Application
对这个概念不熟悉的话可以去看一下
ajax in action的第一章


概念很简单,就看字面意思我也能明白。我的意思:是 One Page, One Application 合适还是 One Page,One Form 更合适? JSVM 中有类似application/module的应用模式,把一个100%*100的Frame作为整个应用的框架页面(这个框架页面作为appliation对象存在,和整个应用的生命周期保持一致)其余页面作为module方式(或称之为应用的一个窗体)在这个框架页面下运行,于是我们可以借助application设计出一个有状态的客户端。今后SOA的架构决定了服务端都将设计成无状态模式,(我们知道无状态可以更好的实现线形扩展),客户端将担负起保存状态的主要责任。
0 请登录后投票
   发表时间:2006-03-02  
概念是简单,问题是接受程度以及代价。
坦白说我是不接受的,给我的感觉就是非要用windows自带的画图程序来画3D效果图,
我承认你做得出来,但是你不累我觉得也累。
有人说某一天windows自带画图程序会大幅度改进,所以我们要先摸索如何用现有windows画图程序来画3D图。
我觉得现在得OPOA也就是这么回事。
0 请登录后投票
论坛首页 Web前端技术版

跳转论坛:
Global site tag (gtag.js) - Google Analytics