测试中，实例化了一个FileUploadBaseView对象f，并设置了它的name属性，通过on方法添加一个跟hello相关的监听器，最后通过trigger方法触发了hello的监听器，并传递了额外的两个参数，在监听器内部除了可以通过监听器的函数参数访问到trigger传递过来的数据，还能通过this访问f对象。
从目前的结果来说，这个方式看起来还不错，但是在我想要继续实现FileUploadBaseView的时候碰到了问题。你看我在设计这个组件的时候那几个订阅相关的option：
我原本的设计是：这些订阅都是成对定义，一对订阅跟某个实例方法对应，比如带before的那个订阅会在相应的实例方法（render）调用前触发，不带before的那个订阅会在相应的实例方法（render）调用后触发，而且还要求带before的那个订阅如果返回false，就不执行相应的实例方法以及后面的订阅。最后这个设计要求是考虑到在调用组件的实例方法之前，有可能因为一些特殊的原因，必须得取消当前实例方法的调用，比如调用remove方法时有的数据不能remove，那么就可以在before订阅里面做一些校验，能删除的返回true，不能删除的返回false，然后在实例方法中触发before的订阅后加一个判断就可以了，类似下面的这种做法：
但是这个做法只能在单纯的回调函数模式里实现，在发布-订阅模式下是行不通的，因为回调函数只会跟一个函数引用相关，而发布-订阅模式里，同一个消息可能有多个订阅，如果把这种做法应用到发布-订阅里面，当调用this.trigger('beforeRender')的时候，会把跟beforeRender关联的所有订阅全部调用一次，那么以哪个订阅的返回值为准呢？也许你会说可以用队列中的最后一个订阅的返回值为准，在大多数情况下也许这么干没问题，但是当我们把“以队列最后的一个订阅返回值作为判断标准”这个逻辑加入到EventBase中的时候，会出现一个很大的风险，就是外部在使用的时候，一定得清楚地管理好订阅的顺序，一定要把那个跟校验等一些特殊逻辑相关的订阅放在最后面才行，而这种跟语法、编译没有关系，对编码顺序有要求的开发方式会给软件带来比较大的安全隐患，谁能保证任何时候任何场景都能控制好订阅的顺序呢，更何况公司里面可能还有些后来的新人，压根不知道你写的东西还有这样的限制。
解决这个问题的完美方式，就是像DOM对象的事件那样，在消息发布的时候，不是简简单单的发布一个消息字符串，而是把这个消息封装成一个对象，这个对象会传递给它所有的订阅，哪个订阅里觉得应该阻止这个消息发布之后的逻辑，只要调用这个消息的preventDefault()方法，然后在外部发布完消息后，调用消息的isDefaultPrevented()方法判断一下即可：
而这个做法跟使用jquery管理DOM对象的事件是一样的思路，比如bootstrap的大部分组件以及我在前面一些博客中写的组件都是用的这个方法来增加额外的判断逻辑，比如bootstrap的alert组件在close方法执行的时候有一段这样的判断：
按照这个思路去改造EventBase是一个解决问题的方法，但是jquery的一个小技巧，能够让我们把整个普通对象的事件管理变得更加简单，下面就让我们来瞧一瞧它的庐山真面目。
2. jquery小技巧模式
1）技巧一
如果在定义组件的时候，这个组件是跟DOM对象有关联的，比如下面这种形式：
那么我们可以完全给这个组件添加on off trigger one这几个常用事件管理的方法，然后将这些方法代理到$element的相应方法上：