opoa介绍

一 定义       One Page, One Application(后面缩写为OPOA,或者1P1A), 含义很简单:一个页面就是一个应用。不再使用iframe, 页面提交不能再使用submit方式。       在众多的基于Web的MIS系统中,没有人关心页面的组织形式;大多数稍微复杂的MIS系统,都采用分祯(Frame)的方式来组织页面,这样,在进行业务操作的时候,url的变化表现在一个框架页面内,从浏览器的地址看起来,只有一个地址;更有甚者,一些应用干脆弹出一个去掉了浏览器菜单、工具条、地址栏、状态栏的窗口(比如招商银行、民生银行的网上银行系统),连地址都看不见。因此,一个页面就是一个应用,从用户的角度来说,对于操作型系统,是一种非常自然的体现。用户无需了解每一个具体的操作对应的地址是什么。       这种设计背后的含义实际是:是希望由程序来控制用户的行为,还是反过来。在操作型系统中,每一步的操作往往被业务含义严格定义,无论是应用的设计者,还是其使用者,都希望在一种受控的状况下来进行操作。例如,一个审批动作,用户更希望是通过一个按钮来触发,而不是访问类似于/approve.action?itemid=123的方式。       这样的好处是:很多东西,例如:JS,CSS,HEAD等整个系统都只需加载一次。加快响应速度。客户体验也有所提高,不再弹出窗口,不再整个页面进行刷新。 二 场景       显然,OPOA的设计只能针对那些对URL不敏感的系统,或者说操作型系统。绝大多数MIS系统都属于这一范畴,Email系统也是这一范畴,其他领域,如监控系统,聊天室等都可以采用这种思路。反面的例子是,对于内容型系统,如新闻系统,Blog系统,论坛系统,用户更希望能够通过一个明确的URL来定位页面内容,搜索引擎也喜欢这种地址。这种应用需要的是一个合理,易懂,明确的地址。 三 设计与实现       大多数MIS系统,无论是有意识或者无意识,都遵循了OPOA的思路。要么采用框架,要么采用弹出窗口来屏蔽URL的直接访问。实现上也很简单,这里就不再赘述了。注意到上述的OPOA地实现只是对用户而言,看起来好像是一个页面一样,但实际上还是有众多的action, page在后面工作。       下面我要说的一种实现是,采用buffalo技术来实现真正意义上的OPOA. 简而言之:主页面(或者称布局页面)只加载一次,其他的操作页面通过buffalo技术来加载,并将其中的操作脚本与布局内容分开,最后进行展示。       首先存在一个布局页面,这个页面定义了一个应用大致的外观,(例如,大部分MIS系统按照上中下三栏,中间部分左右两栏分别为顶部logo, 操作菜单,具体操作内容,底部状态栏)。用你喜欢的网页编辑工具,将这个页面设计美观,然后按照应用的要求,将页面进行拆分。此时的拆分不用Frame了,只需要在不同的部位加上

就可以。 然后在主页面定义一个函数,例如switchPage, 将这个函数使用在需要进行页面切换的地方。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);
            }
    });
}

      剩下的工作都可以想象了。你可以将web应用的网页资源全部用html编写,并放在一个不为人知的地方,而通过pageService来读取他们;你可以任意组织你的应用外观,更加自如的切换他们。应用的URL地址永远只有真正的一个,你的应用也要比别人快很多,因为只加载那么一小块内容。 项目实践过程中遇到的问题:      1. 须保证页面元素ID唯一,全系统JS函数名唯一 [定义一个规范]      2. 回调函数处理 [封闭buffalo提交的方式,增加回调处理]      3. FORM提交 [使用buffalo的form提交]      4. JS加载问题 [使用与buffalo组件绑定的方式加载]     5. 事务同步问题 [通过设置buffalo提交参数,并且自己在回调进行特殊处理]      …… 四 小结       AJAX的兴起为我们开阔了很多视野。比起原来的web框架,这种OPOA的方式能够更快,减少更多的编码量,并提供更好的用户体验。当然,上文中提出的只是一个原型实现,如果尝试自行实现,可能更多的东西需要考虑,如安全,缓存,事件回调机制,内存管理等等。但这将是一个方向,一个可以提高开发体验与用户体验的方向。       这是我们项目第一次使用OPOA思想,在大概一个月的摸索道路上,需要解决的问题是比较多的。而且前期开发的压力也是比较大!思想不同了,处理方式不同了,带来了更高的客户体验! 有得必有失,权衡中间的得失才是最重要的!我们正在成长,在OPOA的道路上!        善于总结,我们就能提高,善于发现,我们就有机会!

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏闰土大叔

回顾自己三次失败的面试经历

前言 时间的齿轮已经来到了2017年的11月份,距离2018年仅仅还剩下不到两个月的时间。站在这个时间点上,我对自己之前三次失败的面试经历做了一次深度回顾。 ...

3319
来自专栏Pythonista

Python之路,Day1 - Python基础1

python的创始人为吉多·范罗苏姆(Guido van Rossum)。1989年的圣诞节期间,吉多·范罗苏姆为了在阿姆斯特丹打发时间,决心开发一个新的脚本解...

842
来自专栏java思维导图

程序员,请优先提高代码的可读性

现在,当有人提及“优化”一词时,他们通常是指“优化执行时间”,除非他们明确表明要优化GPU的内存消耗,网络流量等等。

754
来自专栏Python绿色通道

用Python打造属于自己的搜索引擎

打开Pycharm,然后New Project 选择Flask模块,然后会自动安装Flask库的,这里就不赘述了

1184
来自专栏程序员互动联盟

【专业技能】前端开发眼里的页面

拿到效果图时,有这么几步,就我了解的情况做一下分享,不一定全部都是科学,但可以部分借鉴。 我先说一下,熟练后拿到效果图时这样的一个状态: ? http...

3156
来自专栏哲学驱动设计

Rafy 领域实体框架简介

按照最新的功能,更新了最新版的《Rafy 领域实体框架的介绍》,内容如下: 本文包含以下章节: 简介 特点 优势 简介 Rafy 领域实体框架是一个轻量级 OR...

1867
来自专栏程序员的SOD蜜

PDF.NET 数据开发框架 许可限制 框架源码的获取

欢迎使用 PDF.NET 数据开发框架 (Ver 4.0) 关于框架的名字由来          在我设计www.pwmis.cn 站点(原域名已经过期,现在正...

1906
来自专栏QQ会员技术团队的专栏

Vue.js前后端同构方案之准备篇—代码优化

作者简介:王鹤,高级前端工程师,隶属于腾讯SNG增值产品部。主要负责QQ个性化业务的功能开发及技术优化。业务时间喜欢折腾设计、产品,新技术、理财等。品牌「爱财记...

1988
来自专栏Java学习网

最佳编码实践:搞砸代码的10种方法

 这是一篇提供有效、实用编程方法的程序箴言,作者Susan Harkins是世界最大的技术期刊出版社的主编,具有多年的实践经验;在这篇文章里她重申“最佳编码实践...

2464
来自专栏喵了个咪的博客空间

zephir-(1)开篇介绍

#zephir-开篇介绍# ? ##前言## 先在这里感谢各位zephir开源技术提供者 笔者在学习phalcon的过程中了解到,phalcon2.x版本通过了...

3519

扫码关注云+社区