一。sjs的继承方式
ext(v2.x)的继承方式extend是通过原型链的方式实现
子类.prototype = new F()
F.prototype = 父类.prototype
var obj = new 子类();
obj就有了父类的属性
借助临时函数F的存在，为子类的prototype和父类的prototype架起桥梁。
//父类
test.base = function(cfg){
}
//子类
test.input = function(cfg){
test.input.superclass.constructor.call(this, cfg);
}
//继承
ext.extend(test.input, test.base, {
_renderInner: function(html) {
this._renderInput(html);
}
} ... }
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指令?
等有时间，将错误重现后，再来找解决方案
