[2012-01-06]

一。sjs的继承方式

ext(v2.x)的继承方式extend是通过原型链的方式实现

子类.prototype = new F()

F.prototype = 父类.prototype

var obj = new 子类();

obj就有了父类的属性

借助临时函数F的存在，为子类的prototype和父类的prototype架起桥梁。

?

1 2 3 4 5 6 7 8

//父类<br>test.base = function(cfg){}//子类<br>test.input = function(cfg){<br>    test.input.superclass.constructor.call(this, cfg);<br>}//继承 ext.extend(test.input, test.base, {       _renderInner: function(html) {         this._renderInput(html);<br>    } }   ... }

　　

sjs(simple js)继承实现不一样，严格来说，sjs并不是继承，而是一种mixin，并且允许子类，插件，甚至最终实例对象，都可以自由override任意方法和属性，提供最大的灵活性和扩展性。

不管是继承,mixin,plugin还是最终的config override，都提供统一的overide方式，在子类方法中，都可以用this.callOverride()访问被override的上一层函数。

最终被new出来的实例，其原型链只有一层，即被mixin后的最终对象

显然这种方式比起原型链来说，多了很多次的copy动作，但毕竟是class的构建，加上极短的原型链，在访问实例的属性和方法时，想必对性能影响也不会太大

但是其对于在各个层次，类层次，插件层次，对象层次时提供的统一，简单的override访问，则会得到更多的好处

构造方式大致如下：

var classPrototype = mixin(base,overrides,plugin1,plugin2...);

new F()

F.prototype = classPrototype;

使用时直接new F(cfg)即可

 

二。sjs的UI对象与Html Element的关系

传统的js UI对象，一般与最终输出在浏览器中的对象都是一一对应的，即一个js UI对象，一般对应一个具体的Html Element元素。

这种方式对于开发UI类来说很方便，UI对象任何时候可以通过this.el访问dom，再对dom的原生浏览器event进行attach

但这种方式的弊端就是在grid中的行中的子对象构建相当麻烦

试想一个有500行的grid，每行可能有三个input输入，或是直接显示datepicker这样的对象用于某个栏位的输入。

多达1500次的new动作，再加上事件构造，dom对象引用，然后翻页时又全部dispose，想想就受了不。

 

而再想最原始的处理方式，就是先显示html

中间可能夹了一些onclick，显示直接将td中的html加起来，最后innerHTML就行，方便简单

翻页也无需多恼，直接innerHTML替换新的就好了

 

因此sjs考虑采用这种原始方式

getHtml和事件响应和处理分开

 

一个new好的对象，如果在除了私有数据不一样外，可以一直render

UI 对象保存每一份的数据，并且在id匹配时，自动在程式中使用这个id的私有数据

 

这样，整个框架，一般只有一个datePicker对象，一个monthPicker对象，一个textInput对象

却可以为所有的实例提供对象操作支持。

 

至于外部通过这个对象操作具体的Html Element时，则需要调用一下fly(id)或flyByKey(dataRowIndex)这样的方式先行引用，再进行方法，如datePicker的setDay方法

 

三。ORA-02067: 必須執行交易或儲存點的倒回作業

在发生这个错误后，那台主机（不管IIS应用程序池，以及连接字符串不同）的相同账号访问同台DB都会被Pending住，后台程式不可预料，所以看是否可以在.net服务端统一解决？

捕捉异常，看能否传入rollback指令?

等有时间，将错误重现后，再来找解决方案