|
在ExtJS中的API中對store的load監(jiān)聽有這樣的一段描述,，如下：
load( Store this, Ext.data.Record records, Object options )
當(dāng)一筆新的Record加載完畢后觸發(fā),。Fires after a new set of Records has been loaded
監(jiān)聽器會傳入以下的參數(shù)：
-
this Store -
records Ext.data.Record
加載好的Record（Ext.data.Record[]）,。The Records that were loaded
-
options Object
所指定的laoding操作,。The loading options that were specified
對于這三個參數(shù)：sto,，records和options，用到的最多的sto,，后面兩個很少用到,。在今天開發(fā)的時候，遇到了一些問題,，正是這幾個參數(shù)幫了我的忙,。對于這三個參數(shù)，我找了一下資料,，貼出來：
寫道
API中l(wèi)oad事件回調(diào)的簽名 function( Store this, Ext.data.Record[] records, Object options )
load事件在加載數(shù)據(jù)后出發(fā), 比如autoLoad: true, 調(diào)用load方法, laodData方法, 調(diào)用add方法是不會觸發(fā)的
this : Store, 觸發(fā)事件的store本身的引用, 在定義事件時沒有定義scope的話,
this參數(shù)與函數(shù)中的this指針等價. 在這邊使用this作為參數(shù)名稱比較容易混淆, 函數(shù)參數(shù)與函數(shù)內(nèi)部的this指針是完全無關(guān)的.
應(yīng)避免使用this作為參數(shù)名稱. 一般定義回調(diào)時這樣 function(_store, _records, _ops), 添加_標(biāo)示內(nèi)部變量,
JavaScript變量作用域非常容易引起混亂, 命名規(guī)范非常重要
records : Ext.data.Record[]
The Records that were loaded
大部分情況下等價于store的所有數(shù)據(jù), 有一種特殊情況, 調(diào)用loadData方法指定第2個參數(shù)append為true時, 標(biāo)示保留原有數(shù)據(jù), 那records僅僅是本次load添加的數(shù)據(jù)
options : Object
The loading options that were specified (see load for details)
調(diào)用load方法時提供的參數(shù)對象的引用. 即load事件若是由調(diào)用load方法觸發(fā),
則options參數(shù)即是調(diào)用load方法的參數(shù), 比如通常分頁都會有參數(shù): store.load({params: {start: 0,
limit: 50}}); 則options={params: {start: 0, limit: 50}}
其中對我有用的是options這個參數(shù),，用用處在如下代碼中：
Java代碼:
-
store_loadByIns(isaccStore, {ip: ips[j], dbid: dbids[j]}, "load", function (sto, a, b) {
-
-
if (sto.getCount() >= 0) {
-
unAccessable.push(b.params.dbid);
-
}
-
})
其中b就是這個options，只不過是名字不同而已,。store_loadByIns是公司類庫里的一個方法,，這個方法的第一個參數(shù)一個store實
例，第二個參數(shù)是
需要傳的參數(shù)列表,，以json形式,。第三個是要增加的監(jiān)聽的名字，第四個就是回調(diào)函數(shù),。如果想要在load之后使用傳入的哪個參數(shù),，就得使用
options這個參數(shù)了，就是上面代碼中的b,，b.params.dbid就是加載這個store時候用到的那個dbid,。
|
