OPOA项目实践

One Page One Application单页面应用[OPOA或1P1A],也就是说,一个页面就是一个应用系统,整个系统只有一个页面,不再使用iframe,页面提交不能再使用submit方式。

这样的好处是:很多东西,例如:JS,CSS,HEAD等整个系统都只需加载一次。加快响应速度。客户体验也有所提高,不再弹出窗口,不再整个页面进行刷新。

我们项目是使用dojo进行开发,使用ajax方式提交,当然也可以使用.do的方式提交,只不过返回的话,就是一个页面的信息,这个页面的信息放在一个div里,就像是粘贴过来的页面一样。由于dojo解释,加载时都是比较慢,整个项目如果全部使用dojo的组件,性能可能会有问题。现项目主要使用了dojo,tree,titlepane,layoutpane,contentpane,dialog等主要的组件,丢弃不需要的dojo组件。

项目实践过程中遇到的问题:

1. 须保证页面元素ID唯一,全系统JS函数名唯一 [定义一个规范]

2. 回调函数处理 [封闭Dojo提交的方式,增加回调处理]

3. FORM提交 [使用dojo的form提交]

4. JS加载问题 [使用与dojo组件绑定的方式加载,另一种方式,可以使用dojo的require方式进行加载]

5. 附件上传问题 [使用dojo.io.iframe解决附件上传问题]

6. 事务同步问题 [通过设置dojo提交参数,并且自己在回调进行特殊处理]

……

一点心得:

在OPOA项目中,FORM—ID是一个非常重要的标志,很多元素都是通过FORM去找的。很多页面的交互也是通过FORM_ID去查找。一定要保证ID的唯一!!!

由于使用DOJO,脚本的加载是一个比较大的问题,如果将所有脚本在进入系统时统一加载,这样网络传输的数据也会很大,系统性能有所影响!如果是按需加载,懒加载,可以提高进入系统的响应速度,但因为DOJO的限制,有些脚本不会生效,必须放在特殊的地方,例如:include进来的页面, JS脚本是不会执行的,必须放在包含页面的主页面上。这对于页面比较简单的应用来说,还是可以的,但如果页面交互比较复杂,业务逻辑比较复杂的话,JS将会非常之乱!后续维护工作压力也会比较大!经过一些实验,使用dojo,require机制进行动态加载脚本是一个不错的选择。

例如:可以把一个业务模块的脚本全部放在一起,使用require进行唯一加载!

if(!dojo._hasResource["holly.oss.SDH"]){
dojo._hasResource["holly.oss.SDH"] = true;
dojo.provide("holly.oss.SDH");


dojo.declare("holly.oss.SDH",null,
{
showSDHMsg: function() {
showMsgDialog("haha","成功了!",true);

});

}


这是我们项目第一次使用OPOA思想,在大概一个月的摸索道路上,需要解决的问题是比较多的。而且前期开发的压力也是比较大!思想不同了,处理方式不同了,带来了更高的客户体验! 有得必有失,权衡中间的得失才是最重要的!我们正在成长,在OPOA的道路上!

善于总结,我们就能提高,善于发现,我们就有机会!

相关文章

我有一个网格,可以根据更大的树结构编辑小块数据.为了更容易...
我即将开始开发一款教育性的视频游戏.我已经决定以一种我可以...
我正在使用带有Grails2.3.9的Dojo1.9.DojoNumberTextBox小部...
1.引言鉴于个人需求的转变,本系列将记录自学arcgisapiforja...
我正在阅读使用dojo’sdeclare进行类创建的语法.描述令人困惑...
我的团队由更多的java人员和JavaScript经验丰富组成.我知道这...