周末w3ctech交流会上的分享，combo是一项古老的技术，在门户级别的复杂网站用一下还是不错的
[ view entry ] ( 716 views ) | permalink |
( 3 / 124 )第一种境界：了解各类框架、并熟悉甚至精通某种框架的使用，但并未看过框架代码、或者并不理解框架核心细节的实现，甚至不清楚框架的设计原理、基本思想、适用场景。这类人的编程思路始终限制在”特定框架“的范围内，尽管能使用框架写出满足需求的代码。
这种人停留在”会用“框架的阶段，他们很在乎各种框架的比较，且一定要对框架分出三六九等。这些人写代码的思路始终没有离开”功能实现“。
第二种境界：精通各类框架，熟读各类框架源码，非常了解各类框架的核心功能的细节实现，熟识各类框架的优缺点和适用场景，权衡利弊后理性选择相对适用业务逻辑的框架，并能根据业务的需要有针对性的修改框架核心代码使之更加满足可维护性和性能上的需求，但依然要基于某种框架进行业务开发，框架的范围依然停留在组织代码、第一层的抽象和组件的模块化的范围内。
这种人停留在”精通“框架的阶段。他们的特点是有能力去对框架做有针对性的二次封装，甚至有些人有能力重写框架核心代码，但依然要基于某种框架做扩展和hack。这些人写代码的思路始终在”代码管理和框架级别的抽象“。
第三种境界：异常精通各类框架，同时精通业务逻辑，娴熟的对业务逻辑进行抽象，具备传统软件工程师的基本素质，有能力设计业务框架，并根据业务逻辑的需要重写合适的底层框架。这类人的编程思路已经完全脱离“框架”的限制，达到一种真正自由超然的境界。
这种人已经达到技术方和需求方一致认可的“专家”级别，技术功底扎实、同时精通业务。他们写代码的思路已经完全脱离“框架”，并始终围绕业务逻辑，主要工作即为业务逻辑层面的抽象和接口设计。
那么，你在哪个境界？
[ view entry ] ( 299 views ) | permalink |
( 3 / 104 )看看jquery源码中dom部分的比重就知道dom有多么肮脏和臃肿了，说dom臃肿，到不是因为浏览器差异，而是因为dom本身就不优美，Qcon上老道也提到，天资优雅的javascript被dom污染坏了。因为标签属性类型太多，节点种类和行为又是如此多样，所以对dom的封装不是技术活，纯粹是体力活，过程中需要大量的测试，包括性能测试。所以，封装dom的时候，一定要有耐心。
今天给sandbox的dom添加了一些常规方法，attr,css,style,empty,append,copy等等，行为大都依照jquery-dom的api来做，我删掉了那些性能上的hack，想重写性能的部分，不过这都不是难点，这些方法中，麻烦的是节点的拷贝，因为要考虑事件的拷贝，节点复制一个新的，新节点的事件不能丢。在ie中，原生的cloneNode就可以复制事件，但有点囧。jquery源码中是这样描述事件拷贝的
// IE copies events bound via attachEvent when
// using cloneNode. Calling detachEvent on the
// clone will also remove the events from the orignal
// In order to get around this, we use innerHTML.
// Unfortunately, this means some modifications to
// attributes in IE that are actually only stored
// as properties will not be copied (such as the
// the name attribute on an input).
解决方法似乎是找出所有的问题种类一个一个hack，之前给Node的事件已经封装好，在非ie中，只需要给新生成的节点挂载一个新的"事件中心"，这个事件中心的事件依然指向旧有的节点，实际上两者公用一个回调，这个回调是存储在Sandbox._ENV.Event中的，并不会因为旧节点的删除而消失，因此，demo就是这样：
http://tbexample.googlecode.com/svn/tru ... -copy.html
dom中有太多细节需要考究，并发现jquery内部各模块之间的耦合简直像胶水粘上一样，在模块组织这方面，john真的要向zakas学学了。
下一步，继续杯具的Dom
to be continue...
[ view entry ] ( 3965 views ) | permalink |
( 3 / 169 )不管怎样，总有一些常用的函数是要时时刻刻准备使用的，这些函数并不需要被继承和二次封装，他们只包含一些代码片段，而这些代码片段则很大程度上提高core后续开发效率。这些东西被称之为SDK（Sandbox Developer ToolKit），比如oo中的mix、merge，array中的each和object中的traverse等等，但凡框架都会有一箩筐这种快捷函数，甚至于对Class的模拟、Queue的模拟。。。
这种东西不必在开始就coding进去，因为这种代码片段实在太多了，我也不知道以后会用到哪些，粗糙分下类即可，在框架成型的时候在做统一规整，因为core写完的时候，大概也就知道自己常用那些代码片段了，比如jquery和prototype中对Class的模拟就用不着，mix和原型派生就足够用了。除了sandbox-seed.js之外，基本上sdk处于最底层了，所以依赖关系要先在脑海中形成，sdk是脱离seed而高于seed的，应当属于core-base的base。
想清楚了依赖关系，其实就是这样简单
sandbox-seed > sdk > lang > oo > array|object > dom|node|event|ajax... > widgets(plugin?) > app...
总之，SDK是必要的，参与“机制”的一部分组成，对高层的dom\node\event提供支持，ok，这些不是重点，重点是dom，万恶的dom
下一步，万恶的dom
to be continue...
[ view entry ] ( 359 views ) | permalink |
( 3 / 155 )残酷的现实告诉我们，dom需要封装，更加残酷的现实告诉我们，dom不仅需要封装，还需要格式统一，毕竟，B端的开发无论如何是离不开dom、离不开node的。统一规格的node模型能让我们减少很多思考时间，这一点jquery显然是考虑不周，因为，事件不仅需要“被操作”，“事件”中还包含很多有用的重要信息，因此，Node中的event，也是需要规格统一，虽然$方法可以很方便的wrap一个dom节点，但还是需要花上几秒钟想一想这个dom是裸的还是封装过的。这些都是后话，这里要区分的，NodeFacade和DomEventFacade是不一样的，一个用来封装dom，一个用来封装裸的event。在yui3中，Node和Nodelist是不一样的，其实，既然选择了Sizzle，就不用再区分node和nodelist了，只需要在细节上稍作hack即可，比如node(list)下面的query等等，实现不是问题，要看如何设计node(list).query下的行为来解决歧义的问题。在Node的事件Facade上，做到尽量的简化，这里的Node只要包含常用的on、detach、detachAll，并hack了一下浏览器。
NodeFacade的事件相关的interface就是这样，另外，DomEventFacade我偷懒了下，直接使用yui3的DomEventFacade，简单hack下就可以用，还是不错的，事件冒泡和阻止都在这里了。demo在这里
http://tbexample.googlecode.com/svn/tru ... ent-1.html
另外，要特别注意下Node和Event之间的关系，概念上，两者是应当分开的，实现上，两者是杂糅在一起的，但还是尽量将他们分开，并让Node依赖Event，Event依赖Event-Custom，这样做可以让DomEventFacade的实现看起来像event核心的东西。不过这种拆分都不重要，仅是一种代码组织方式，完全解耦，似乎是不可能的，只要尽可能的解耦就好。
搞到这里，似乎Node的基本“机制”性的东西都已经有了架子，剩下的，就是去做一些纯工作量的事情，比如addClass、removeClass、toggleClass、attr等等，看起来更像tools了。其实，除此之外，框架还是应当包含必要的tools的，比如array和object的相关tools，当然，还有oop的一些东西，这些都应当脱离框架的“框架”，这些东西我们统一称之为SDK，其实到现在我没怎么思考框架的名字，反正也不重要，就叫Sandbox吧，Sandbox Developer ToolKit = SDK，Sandbox简称SB，也挺好的。
下一步，SDK
to be continue...
[ view entry ] ( 570 views ) | permalink |
( 3.1 / 141 )
