在store中加load事件

本文详细介绍了ExtJS框架中Store的load事件及其应用场景。包括如何通过load事件监听加载新记录的过程,以及如何利用事件参数进行后续处理,特别是对options参数的应用案例。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >



监听store的load:

此文为自己备忘用的,,

为store添加事件

store.addListener('load', function(st, rds, opts) {         // st 是当前的store, rds是读到的Record[], opts是store的配置        //alert(rds.getTotalCount());         //nextstore.removeAll(); //先清除另一个store的内容        //nextstore.add(rds); // 给另一个store添加这些records         //for( var c=0; c<rds.length; c++ ) store.addSorted(rds[c]);

       department.setValue('GGFYZX');//加载完后就可以设置初始值});

 

load( Store this, Ext.data.Record records, Object options )

当一笔新的Record加载完毕后触发。Fires after a new set of Records has been loaded

监听器会传入以下的参数:

this Store

records Ext.data.Record

加载好的Record(Ext.data.Record[])。The Records that were loaded

options Object

所指定的laoding操作。The loading options that were specified   

 

对于这三个参数:sto,records和options,用到的最多的sto,后面两个很少用到。在今天开发的时候,遇到了一些问题,正是这几个参数帮了我的忙。对于这三个参数,我找了一下资料,贴出来:

 写道

API中load事件回调的签名 function( Store this, Ext.data.Record[] records, Object options )

load事件在加载数据后出发, 比如autoLoad: true, 调用load方法, laodData方法, 调用add方法是不会触发的

this : Store, 触发事件的store本身的引用, 在定义事件时没有定义scope的话, this参数与函数中的this指针等价. 在这边使用this作为参数名称比较容易混淆, 函数参数与函数内部的this指针是完全无关的. 应避免使用this作为参数名称. 一般定义回调时这样 function(_store, _records, _ops), 添加_标示内部变量, JavaScript变量作用域非常容易引起混乱, 命名规范非常重要

 

records : Ext.data.Record[]

The Records that were loaded

大部分情况下等价于store的所有数据, 有一种特殊情况, 调用loadData方法指定第2个参数append为true时, 标示保留原有数据, 那records仅仅是本次load添加的数据

 

options : Object

The loading options that were specified (see load for details)

调用load方法时提供的参数对象的引用. 即load事件若是由调用load方法触发, 则options参数即是调用load方法的参数, 比如通常分页都会有参数: store.load({params: {start: 0, limit: 50}}); 则options={params: {start: 0, limit: 50}}

 其中对我有用的是options这个参数,用用处在如下代码中:

Java代码:

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);  

               }  

           })  

      this.store = new Ext.data.Store({
            proxy : new Portal.Util.CMBDataProxy({
                operation : {
                    prccod : "DBDWSTBQ"
                },
                requests : {
                    "DBDWSTBQX1" : function(params) {
                        return [ {
                            'qry_key' : params.name,
                            'fun_id' : params.funId
                        } ];
                    }
                },
                responses : {
                    datasNode : "DBDWSTBQZ1"
                }
            }),
            reader : new Ext.data.JsonReader({
                idProperty : 'id',
                root : 'root',
                totalProperty : 'total',
                fields : [ {
                    name : 'tbl_id'
                }, {
                    name : 'tbl_eng_nm'
                }, {
                    name : 'tbl_chn_nm'
                }, {
                    name : 'blg_datarea_id'
                },{
                    name : 'dat_db_id'
                }]
            }),
            listeners:{
                load:function(){
                    if(this.data.length<1)
                    msgTip = Ext.MessageBox.show({
                        title:'提示',
                        width : 250,
                        msg:'当前数据库无匹配结果'
                    });
                }
            }
        });
        dws.designer.QueryTableGrid.superclass.initComponent.call(this);
    },

### LoadLoadLoadStore 的定义与区别 #### 定义 LoadLoad 是一种内存屏障类型,用于确保在某个特定的加载操作之前的其他加载操作不会被重排序到该加载操作之后执行[^4]。 LoadStore 则是一种不同的内存屏障类型,它保证在一个特定的加载操作之后的所有存储操作不会被重排序到该加载操作之前执行。 #### 使用场景 - **LoadLoad** 常见于多线程环境中,当多个线程需要访问共享变量并依赖这些变量之间的顺序关系时。例如,在一个线程中先读取标志位再读取数据的情况,可以使用 LoadLoad 防止编译器或 CPU 将两个读取操作重新排列。 - **LoadStore** 主要应用于需要严格控制加载和存储之间顺序的地方。比如在线程间通信中,如果一个线程负责设置某些状态标志,而另一个线程则依据这些标志来决定是否更新全局变量,则可以通过 LoadStore 来防止存储操作提前发生。 #### 区别 主要的区别在于它们所保护的操作范围不同: - **LoadLoad** 只影响加载操作间的相对次序; - **LoadStore** 影响的是加载操作相对于后续存储操作的关系。 以下是两种屏障的一个简单伪代码示例: ```c++ // LoadLoad 示例 int flag = 0; int data = 42; void thread1() { int temp_flag = atomic_load(&flag); // 加载 flag memory_barrier_loadload(); // 确保所有前面的加载完成后再继续 if (temp_flag == 1) { use_data(atomic_load(&data)); // 使用 data } } // LoadStore 示例 bool ready = false; int result = 0; void thread2() { int local_result = compute(); memory_barrier_loadstore(); // 确保加载完成后才允许存储 atomic_store(&result, local_result); atomic_store(&ready, true); } ``` 上述例子展示了如何通过引入合适的内存屏障来维护程序逻辑的一致性和正确性。 --- ### 性能消耗分析 关于 `atomic_store_explicit` 和 `atomic_load_explicit` 使用 release/acquire 的性能开销问题,通常情况下 acquire/release 模型相比更强语义(如 sequential consistency)会带来更低的同步成本[^3]。这是因为 acquire/release 不强制要求整个系统的全局一致性视图,而是仅关注单一线程视角下的事件因果关系。 具体来说: - Release 序列化当前线程中的入动作,并通知其他核心上的观察者; - Acquire 负责确认接收到最新版本的数据副本后才能进行下一步处理。 这种机制减少了不必要的锁竞争以及跨 NUMA 节点传输带来的延迟,从而提高了并发应用程序的整体效率。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值