在介绍了YUI自定义事件体系和对DOM事件的封装后，本篇文章重点阐述事件方面的一种常用技术——事件代理。事件代理（Event Delegation，又称事件委托）充分运用事件传播模型，用一种十分优雅的方式实现了批量节点事件监听。具体的原理和优点请移步zakas比较古老的一篇文章Event delegation in JavaScript。事件代理在YUI中的实现为Y.delegate。
为方便讨论，约定以下名称：
event.target。三者的层次关系从内到外依次为：目标节点 <= 被代理节点 <= 代理节点。
在介绍了由Y.Do、Y.CustomEvent、Y.EventTarget构建的自定义事件体系后，本篇文章将为大家介绍建立在这一体系之上，YUI对DOM事件的封装——Y.Event。
众所周知，浏览器之间存在大量的不兼容问题，在事件方面尤其如此。Y.DOMEventFacade主要用来处理DOM事件对象的浏览器兼容问题，提供跨浏览器的简洁接口。事实上，我们常在Y.one('.selector').on('click', function (e) {})中使用的e就是Y.DOMEventFacade的实例。
上两篇文章YUI事件体系之Y.Do、YUI事件体系之Y.CustomEvent中，分别介绍了YUI实现AOP的Y.Do对象，以及建立自定义事件机制的Y.CustomEvent对象。
本篇文章，将要介绍YUI事件体系集大成者、最为精华的部分——Y.EventTarget。
DOM事件中的目标元素为event.target，这类元素可以触发、监听一些事件，例如input元素的click、focus等事件。这也正是Y.EventTarget的命名渊源，它提供了一种让任意对象定义、监听、触发自定义事件的实现方式。
从设计上看，Y.EventTarget通过内部维护一系列Y.EventCustom对象，提供了可以通过事件名称进行事件定义、监听和触发的便捷接口。另外，推荐使用Y.augment将它以组合的方式加载在其它类上，而不要使用继承。关于Y.augment和Y.extend之间的异同，可以参考我之前的一篇文章：Y.extend与Y.augment。
YUI很多基础类都扩展了Y.EventTarget，重要的有Y(YUI instance，sandbox)、Y.Global、Node、NodeList、Base等。
YUILibrary有专门一个章节介绍EventTarget，非常详尽，如果你对EventTarget的设计思路和使用方法感兴趣，请移步YUILibrary-EventTarget。
上一篇文章中，简要介绍了YUI实现AOP的Y.Do对象。
接下来，我们继续对YUI事件体系进行探索。本次要介绍的是Y.CustomEvent对象，从命名上就可以看出，这个对象在整个YUI事件体系中十分重要。它建立起整个自定义事件的体系，而且，DOM事件也构建在这个体系之上。
Y.Subscriber的作用比较简单：执行回调函数。
Y.Subscriber = function(fn, context) {
this.fn = fn; // 回调函数
this.context = context; // 上下文
this.id = Y.stamp(this); // 设置唯一id
};
Y.Subscriber.prototype = {
constructor: Y.Subscriber,
// 执行回调函数
notify: function(args, ce) {
if (this.deleted) return null;
var ret;
ret = this.fn.apply(this.context, args || []);
// 只监听一次
if (this.once) {
ce._delete(this);
}
return ret;
}
};
Y.CustomEvent主要作用是：建立自定义事件机制，为方便的进行事件创建、监听、触发提供良好基础。自定义事件机制，实际上是Publish–subscribe Pattern(Observer Pattern的演化)的一种实现，这种机制能够方便的实现模块间解耦，增强模块的扩展性。
YUI团队在种种场合不断的夸耀自己的事件体系是多么强大：
事实的确如此吗？就使用YUI的开发者反馈来看，应该是不错的：
作为一名YUI用户，我对其事件体系的强大深有体会。从本篇文章起，我将对YUI事件机制做一个全面分析。
本次我们介绍的是比较基础的两个对象Y.EventHandle和Y.Do。千里之行积于跬步，YUI整套事件机制也是从这两个对象开始构筑的。
很长一段时间内，我都没有搞懂YUI3 OOP模块中的Y.extend方法与Y.augment之间的区别，尽管它们的名称如此显著。现在有些时间，我相信分析源码是最好的解决方法。为了减少不必要的干扰，我简化了这两个方法，使它们仅处理类构造器。
Y.extend方法应用的场景很简单，就是继承。我们知道，JavaScript有多种继承方式，例如原型继承、构造器继承、组合继承、寄生继承等等。YUI采取的为寄生组合继承（Parasitic combination inheritance）。
Y.extend的简化代码如下：
Y.extend = function(r, s) {
var sp = s.prototype, rp = Y.Object(sp);
r.prototype = rp;
rp.constructor = r;
r.superclass = sp;
return r;
};
Y.Object = function(o) {
var F = function() {};
F.prototype = o;
return new F();
}
If an error is possible, someone will make it. The designer must assume that all possible errors will occur and design so as to minimize the chance of the error in the first place, or its effects once it gets made. Errors should be easy to detect, they should have minimal consequences, and, if possible, their effects should be reversible.
–Donald Norman, author, The Design of Everyday Things
我觉得后端工程师较前端工程师最大的便利之一就是：良好的代码监控机制。
每次后端工程师上线后，如果PHP运行中出现错误，会立即记录在error log中，并由脚本根据不同的错误级别进行邮件、短信报警。前端工程师在这方面被动很多，大多数情况下是通过用户反映给客服，然后客服再通知技术部门解决，中间的链条甚至会更长一些，因此前端方面的bug造成的影响往往较为严重。
有什么办法可以缓解这一点，能够让我们在错误面前变被动为主动，第一时间解决问题呢？下面就介绍一种简单的Javascript错误监控机制。
如上图所示，一个错误发生后，首先会被try-catch处理，如果没有被停止，则继续传递给window.onerror处理，如果没有被停止，则最终传递给浏览器控制台处理。
很高兴能够作为东道主参加w3cTech。
在我看来，前端行业更加团结、热情，有非常开放、分享的精神。非常喜欢这个行业的风气。
此次交流会，我做了关于我们团队在YUI3方面的一些实践（YUI3在美团），虽然还很初级，但我们在慢慢强大。在行进中开火，纵情向前！
