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的道路上！

       善于总结，我们就能提高，善于发现，我们就有机会！

One Page, One Application(后面缩写为OPOA，或者1P1A)， 含义很简单：一个页面就是一个应用.而不是一个系统！