EXT设计的方式

在开发EXT的前台应用程序的时候,采用什么样的开发模式,每个人都有自己的一套看法与主张,也都有各自的设计模式.但是就前台页面间的通讯而言应该可以分为单页面与多页面或部分单页面,至于如何去区分,主要是看页面区域的划分与frame的使用情况.究竟是单页面好,还是多页好,我觉得没有一个固定规则,还是要看具体的情况,但有点是可以肯定的就是frame大量使用对效前台的效率是一个考验,因为iframe渲染确实相当的耗费资源.但是如果大量采用ajax的请求,后台服务器收到的请求将会成倍增长,因此需要综合的考量.

如果采用单页面模式来设计,每个设计人员设计出代码也是各不相同,因为这设计到很多方法与结构上的问题,如前后台的数据沟通格式设计;前台代码的模块划分;前台代码的书写规范,有的程序员喜欢直接使用组件对象的写法,而有程序员比较倾向于配置型的写法,我则更喜欢配置形式的写法;另外还有诸入脚本代码是否采用了按需加载的方式等等...这些情况汇聚在一起将会出现的情况是可想而知的.

最近在对整个程序的结构进行调整,遇到了不少问题,以前程序模块采用iframe加载的模式,速度有些问题,因此想把模块加载的部分采用单页面模式,其中遇到了不少问题,在这里将它们记录下来,以备日后查看:

1. 第一个遇到的问题是区域更新:在EXT中使用border布局是很常见的情况,但是如果要动态更新区域的内容就比较麻烦,这里有多种方式可以进行选择:如果用panel的update向后台请求脚本直接运行,或直接请求后返回一个页面的方式等.我采用的方式直接使用remove当前需要替换的区域的组件,然将将新的组件添加到父容器中进行重新布局的方式,但是这种设计对于border布局是不可用的,因为border布局一旦子组件渲染完成后它就不会再行子组件的渲染操作,而只进行布局的处理.可以参考下面的borderLayout文件中的onLayout方法,在borderlayout布局管理器中有一个标记rendered标记,它与组件中的rendered标记有类似但又不完全相同的作用.下面的代码我进行了部分修改以满足动态处理的需求,当然对于非动态的情况是兼容的.使用时只需要将borderlayout布局管理器中的rendered标记改为false就会重新触发子组件对象的渲染的流程,并生成新区域对象,这种改的代价是最小的,但它也有一个局限性,就是对于已经渲染的组件被添加到borderlayout区域中是不支持的,它只支持新添加的组件是还未渲染的情况.对于这种remove再add的设计模式其实还有一种变通的方法,就是在动态的那个区域中添加一个额外的面板而这个面板采用fit布局或card布局也是可以,但是它就是需要多加几个额外的面板层,它的优势在于不需要修改源代码.但相比之下我更喜欢第一种方法,即修改下面的源代码.

    onLayout : function(ct, target){
        var collapsed;
        if(!this.rendered){
            target.addClass('x-border-layout-ct');
            var items = ct.items.items;
            collapsed = [];
            for(var i = 0, len = items.length; i < len; i++) {
                var c = items[i];
                var pos = c.region;
                if(c.collapsed){
                    collapsed.push(c);
                }
                c.collapsed = false;
                if(!c.rendered){
                    c.cls = c.cls ? c.cls +' x-border-panel' : 'x-border-panel';
                    c.render(target, i);
              //2011年为进行动态支持将下面的内容移入条件内
                //以下是一个些后续操作及事件处理,要实现动态处理,这里最好放在上面的条件之内,
                //但这样还是会存在问题,即有一个组件已经是被render过的是从其它容器移过来的就存在问题
                this[pos] = pos != 'center' && c.split ?
                    new Ext.layout.BorderLayout.SplitRegion(this, c.initialConfig, pos) :
                    new Ext.layout.BorderLayout.Region(this, c.initialConfig, pos);
                this[pos].render(target, c);
                }
                /*
                this[pos] = pos != 'center' && c.split ?
                    new Ext.layout.BorderLayout.SplitRegion(this, c.initialConfig, pos) :
                    new Ext.layout.BorderLayout.Region(this, c.initialConfig, pos);
                this[pos].render(target, c);
                */
            }
            this.rendered = true;
        }

1. 第二个问题还是与区域的更新有关,就是区域应该对更新调用者提供接口设计.什么意思呢?如果一个区域的替换如果仅仅是简单的替换而已,则没有这样一个说法,而在实际的业务中并不只是简单的区域替换,例如一个区域中有一个表单,如果用户进行了修改,用户并没有保存,则进行强制的替换是不合理的,如果当前区域与新区域是同一个区域是同一个区域,或是同结构区域只是数据不同而已,这时你可能想不做任何操作或只刷新数据而不更新区域,对于这些情况我想可以通过两种方式来实现:接口方式例如所有区域都实现beforereplace方法,如果返回false则不更新,否则就更新区域,或使用事件方法,更新调用者为当前区域发布beforereplace事件,如果监听者不确认则不更新区域,否则就更新区域,至于两种方案哪一个更优秀有待于将来验证.
2. 第三个问题是一个比较常见的问题,在EXT中设计到组件与子组件的迭代问题.其实在EXT的container容器中已经给出了设计思路就是bubble与cascade方法这两个方法一个是向上的迭代一个是向下的迭代,并在迭代的过程进行回调处理.在树组件结构中也实现了这种迭代模式，只不过并不是在treepanel中实现，而是在treeNode中实现的。在gridpanel、treepanel这些组件中这些方法被屏蔽了（实际是有的），只是不推荐使用而已，因为它们布局是特殊处理的，也没有items属性。在处理实际的迭业务时主要有两个使用方向：回调方法站在一个处理实际业务者的角度来完成所有业务的处理，这种处理方式很有局限性，因为实际业务的不断变化会让回调方法变得特别的复杂，进而到后期变得难以维护；另一个使用方式回调方法站在一个委托者的角度来进行业务规范，而不进行实际业务处理，因为实际业务千变万化，而且不断变化，要让回调方法跟着实际业务跑，总是不太好，各自的业务自己负责，回调方法只是规范业务的接口与流程，这样更容易抽取框架的公共代码。例如组件的刷新问题，通常在执行完成一个操作后希望刷新视图，各个组件有各自的刷新逻辑，如果回调方法想处理所有刷新逻辑是比较困难的，但是回调方法可以委托组件各自规范接口方法来完成操作，当然这个规范是在回调方法中规定的；又例如有这样的业务希望在某些模块中显示模块路径，这最好不要将业务集中在一个方法中来完成，使用委托来搜集模块名称的路径信息应该是最好的方法。采用委托方式有一个比较大局限性就是在进行业务处理的时候组件之间不可相互依赖。