在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 Storerecords 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ù)，用用處在如下代碼中：
- store_loadByIns(isaccStore, {ip: ips[j], dbid: dbids[j]}, "load", function (sto, a, b) {
- // alert(a.length);
- 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。
http://www.software8.co/wzjs/java/1787.html