我们使用dom原生事件的经验是，直接使用node.onblur = new Function即可，只要知道浏览器在打开页面之初都会给每个dom节点发布事件、我们只要用，不需要知道事件是哪里来，将要到哪里去，因此，自定义事件也应当做到如此，需要开放出来的只是fire事件的时刻和事件的回调绑定，这样的话，为什么还需要“发布”事件呢？我至今都想不通为什么yui3的事件需要“发布”？我在埋藏fire点的时候自动注册完事件不就完了？另外，事件的集合是可以做成模板的，比如页面中所有的a标签事件都是一样的，所以这些a都公用一个事件模板，这个事件模板被称之为“事件工厂”。而这个模板并不需要new的时候就固定下来，动态注册事件是不错的选择。毕竟，我给a绑定一个click事件，根本不会去管a还有哪些事件，用哪个事件模板，基于此，demo在这里：
http://tbexample.googlecode.com/svn/tru ... event.html
S.Event.Target就是一个事件工厂，本不需要用它再去做派生。这样事件模板就可以这样new出来
var EventCenter = new S.Event.Target();
绑定事件和埋藏fire和yui3的自定义事件策略一致，并省去了对Queue、Do和EvenType的依赖，看起来也轻巧许多。但在Node的扩展上，还需要实现代理和dom的冒泡等等，这些都交给Node去扩展好了。
下一步，Node事件模型
to be continue...
[ view entry ] ( 294 views ) | permalink |
( 3 / 131 )前些日子写了一个模块的半自动加载，实现了一个最基础的沙箱逻辑，我理解的沙箱是处理模块依赖关系的闭包，闭包之间的串接、调用、依赖均由沙箱机制解决。yui3给我们开了一个好头，但它考虑的事情太多、以至于看起来不美，因为开发者coding的时候尽管可以指定该模块的依赖，脑海中依然有一个构建好的模块树，要不然他怎么知道我依赖什么。如果不考虑性能，开发者的视野可以进一步解耦，甲只知道模块A依赖B和C，B和C各自的依赖由各自作者去解决，所以，沙箱可以加强一些，至少在loading script的时候，动态构建依赖树是完全可操作的。这样可以按照功能将模块颗粒化，yui team处于性能的考虑，很多module被强制添加到一起，也导致高层core实现并不简洁，比如Node和Event之间的解耦不清晰，“机制”和“工具”的解耦不清晰等等，这让core中的各个模块之间层次感不强，功能强大但也略感臃肿，在比如yui.js中就包含了很多脱离了core语义的东西，除了YUI类的实现之外还参杂了很多不必要的Array、Object、和Queue。因为实际上，YUI()的Sandbox是yui3的"框架"，后续开发只是对Dom、Event等的实现并通过Sandbox排序并链接起来，所以，Sandbox的管理模块机制是完全可以独立出来的，像Sizzle一样，就像这样：
http://tbexample.googlecode.com/svn/tru ... ndbox.html
另外，Sizzle是可以直接拿过来用的，作为一个sub-module，sizzle是一个不错的选择器引擎，至少比yui的强多了。
ok，框架的基本框架有了，就可以更进一步实现一些核心了，这里要尤为注意的，框架的core是分层次的，因为裸写Node和Event实在是有些吃力，因此，需要一些更加基础的策略上的东西来将Node和Event支撑起来，就好象盖房子要打地基，不是上去就盖的，这一点john做的很完美，因为这些本应属于框架服务性质的机制也被良好修饰，可以被普通开发者使用，所以jquery的利用率是比较高的，每一处细节都精心设计过，都不会过度浪费，反观yui就有些杯具了，因为为了对Dom、Node和Event的封装而做了大量复杂的基础性工作，包括widget-base的模型设计、代码重用的设计、widget和Dom一致性的设计等等，这些设计一方面给yui3打造一个夯实的基础，保证了yui3在扩展性上的超级灵活，另一方面也带来了更多的资源浪费，因为多数开发者甚至不知道自定义事件、消息队列、插件机制、AOP、事件模型(EventFacade)和节点模型(NodeFacade)等等，多数开发者似乎也不会去关心自定义事件能干什么、插件是干嘛的、什么是AOP，用最高层的api就可以完成大多数工作，为什么还要费心巴力的去看这些？所以，除非做关键扩展、一般是不会用到这些框架“机制”性的东西的，对于普通开发者来说，显然是巨大的浪费。当然，也正因为基础扎实，yui3才能更加游刃有余的应对超级复杂多变的前端开发。
在我看来，“机制”性的东西要有，但不要复杂，能搞定工作上的事情，就可以了。
下一步，自定义事件。
to be continue...
[ view entry ] ( 350 views ) | permalink |
( 3.1 / 138 )出差的时候，有幸在懒懒交流会上听到爱民关于“架构”的分享，虽然抽象，但仍能体会到“架构”的很多道理在YUI3设计中延伸的种种实践。尤其在前端框架满天飞的今天，这种对设计基本原理的抽象依然能让人感触颇深，以至于让我有一种写框架的冲动，与其冲动，不如动手开始。其实，框架的重点在于设计，而不是实现，因为，不管哪个框架，对于浏览器兼容的hack和event的第一层封装都是大致相同的，而各框架对B端开发的理解和设计理念则是千差万别，由此产生的设计原理也大相径庭，不同的设计所派生的各自精妙的实现则带给人们完全不同的使用体验，从某种意义上讲，我们今天“这样”用框架也是被设计好的，不管是各种模式化的业务场景、api的模样、整洁的接口和链调用、还是规格统一的widget库以及各自提供的tools，我们在经历这些东西的时候，已经在不知不觉的按照设计师设计的套路在思考做事。因此，不管是dojo、mootools、还是jquery和yui，在研读他们源码的时候，我们都能清晰的感觉到他们的思想的差别、境界的不同、设计习惯的分歧和性格冲突，编程高手永远用最清晰的代码来表达思想，而代码丛中处处掺杂着精妙的修饰，则带给人无穷无尽的想象。
话说每个简洁的接口背后总有一堆龌龊的实现，这条真理显然可以应用到现有流行的框架上。java的多态似乎想解决这个问题，使用方法重载达到接口的自适应能力，但在js中缺乏机制的支持，则不得不采用大量的hack来污染代码，这在动手写框架之前就应当明白，因为浏览器差异的存在，以及js对于多态的防疫，除非像zakas和john这样的天才，我这种普通人也只能遵守使用“龌龊的代码”去实现“整洁的接口”这条真理了。
另外，需要时刻提醒自己，写框架，始终是一种冲动，仅仅是冲动而已，不要深陷其中，只有天才能绕进去再绕出来，我这样的如果真绕进去，就出不来了。。。需要特别注意的，开始之前一定要搞清楚框架的使用者，以及大概的业务场景，我当然搞清楚了，写好框架自己用，业务场景嘛，工作，不就这么多事情吗。更何况，这样更能促使自己去琢磨每个框架的细节实现，对自己也是一个提高。何乐而不为呢。
to be continue...
[ view entry ] ( 266 views ) | permalink |
( 3 / 118 )终极的前端开发仍然遵循最基本的设计模式、以及模块解耦和最基础的抽象。越来越强烈的感觉到java和c++式的传统设计模式才是软件开发领域的终极哲学，前端开发也不例外：因为解耦的唯一的key就是——接口——万事万物沟通的唯一优美的管道。
在淘宝彩票的重构过程中，这一点是体会最深刻的，并意外的发现数字彩框架部分的js core代码从241k精简到了41k。现在回过头来看js设计模式，其精髓依然是“接口”，而由接口派生出的封装、集成和多态的思想，是贯穿与所有编程语言、和稍微复杂点的应用开发。
因此，任何程序的可读性和可维护性的指标，盖源于开发者对于接口的理解并实践的程度，在快餐式的前端开发中，似乎已经没有多少人再去沉下心去领悟传统设计模式的精妙所在了。
[ view entry ] ( 1083 views ) | permalink |
( 2.9 / 141 )这是我在本周珍珠奶茶会上做的分享。编码的细节太多太多，对于前端工程师，掌握主流常用的编码就可以了，并知晓后端处理URL编码的基本思路以及浏览器在处理编码问题上的差异性。
ps：补充一点，encodeURIComponent和encodeURI，可以参照玉伯的例子
http://lifesinger.googlecode.com/svn/tr ... _test.html
[ view entry ] ( 1679 views ) | permalink |
( 3 / 134 )
