——沙箱是一个工具。就和键盘和鼠标一样，我们需要他，但更要看我们怎么用他。
目前来看，js沙箱的优势在于代码的组织并向“应用”提供架构支持，js沙箱解决不了全局变量污染，多版本库的融合等基本问题，很多人对js沙箱抱有太高奢望，也是不对的。
——沙箱是一把利器。就像AK是巷战之王，可还是有人硬要拿它打飞机。
js沙箱已经开始影响B端开发，而且在前后端融合方面具有更多前瞻性的优势。
——沙箱是一把钥匙。ajax的流行改变了B端开发模式，我们有理由期待js沙箱在企业级开发中的表现。
[ view entry ] ( 924 views ) | permalink |
( 3.1 / 167 )续上篇
程序层面，重点是？
框架包含：核心(core)、适配器(adapter)、基础接口(public api)、代码管理(sandbox & plugin)、组件库(widgets)，显然，框架的重点在于基础接口、和代码管理机制的设计。widget的实现是基于框架提供的public api，public api interface一旦定型尽量不要更改，也就是说，设计要遵循编程基本原则：面向接口，而不是面向实现，这个原则的基本要求是接口的稳定性。因此，框架版本升级导致接口更改的情况可以不考虑？
;)
框架设计师应当将有限的精力放在adapter、public api、sandbox & plugins上，以保证框架基础逻辑设计思路清晰，widget和外部plugin的实现则是纯粹工作量的堆积，可以由更多的人参与开发，以分担框架设计师的工作。
需不需要对core进行重构？
比较纠结的问题是，要不要对core进行重构？即将适配器以下都由自己重构，完全放弃现有的jquery或者yui，这个看情况，个人认为，使用现成的“库”是比较聪明的选择，开源的初衷不也是这样吗？我们要做的，只是将jquery式的api或者yui式的api转换成我想要的api格式即可，api的实现，有什么重要呢？
开发者的角色？
框架设计：框架设计师着力设计public api和sandbox & plugin，adapter可以另有人做，只要对adapter有规范完整的黑盒测试即可。
widget开发：可以由更多的人基于pbulic api开发大量的widget，入库保证有code review即可。
应用开发：任何人基于sandbox和widget都可以开发app了。
各自的视野？
对于框架的使用者来说，他们的视野仅限于sandbox、plugin usage、widgets，手旁只要准备一本public api手册就天下无敌了。对于框架开发小组来说，着重维护widget和api，把项目中的widgets不断抽离、code review并入库。对于工程师来说，他们的视野是一本手册和一些demo，没有必要理解框架的细节。对于那些业余的人来说，让他们一眼看到这个框架有这么多widget和demo，他们就会傻乎乎的开始用了。。。
因此，框架的开发，在于专业、在于坚持、在于团队，三者缺一不可。。。
to be continue...
[ view entry ] ( 568 views ) | permalink |
( 3 / 169 )为什么我们还要做前端框架？
一方面，我把这个看成“学习”和“实作”的问题。对于既有的js库、框架，我们的态度只是学习和使用。我们学习再多，使用再多，也只是增强了学习和使用的能力。开发框架的能力并没有加强。
学会使用与学会制造是两回事情。更进一步的话题，是不能因为别人能制造，我们就不需要学制造。因为别人会制造轮子，并且必将越造越好，但我们却一直是不会。
中国在很多传统行业和IT行业中的很大部分上，已经成为了“全球工厂”了，确切地说是“全球代工工厂”。根源是在于我们不会，一直不会。现在不会，将来也不会，因为过去我们总在说“人家有比我们好的轮子，拿来用就可以了”。
另一方面，现有的所谓框架多指jquery、yui、mootools这些“范库”，在企业级开发中充当tools的角色，针对不同的应用，要基于“范库”构建DPL，而这些“范库”提供的零散widgets是远不能满足需求的，毕竟，商业应用对widgets的质量要求明显要比海量平民化的“plugins”高很多。因此，针对企业级的开发构建DPL，也被称之为“框架开发”。显然，这里的“框架”是更高端更具针对性的。不同于更底层的“范库”的设计。
框架的使用者是谁？
这是任何软件和系统的设计之初都应当清楚的，软件设计给谁用？框架的目标使用者是谁？在淘宝，做框架是给淘宝的WD和工程师用的，在腾讯，框架是做给腾讯的工程师用的，因此这里的框架的使用者和“范库”有本质区别：我们是给特定的人群设计的框架，不是给互联网鱼龙混珠的哪些爱好者们用的。
框架的直接商业价值和间接商业价值？
直接商业价值：形成企业级规范，减轻业务开发负担，使生产率有质的飞跃，并降低成本。
间接商业价值：这种专业性更强的框架更具学术价值。
前端框架所承担的角色？
首先，框架应当和“范库”功能类似，提供现成的widgets和模式库，用于快速构建更高层的上层应用。再者，提供解决团队冲突、代码共享的基本机制，形成团队开发基本模式(显然“范库”无法做到这一点)，也就是说，框架应当具备万行以上的代码量的管理能力。第三，融入全站系统架构中，作为全站前后端架构的组成部分，完成前后端合作的平滑高效(这也是“范库”无法做到的)。第四，高性能和可维护性的平衡。
ok，以上是设计框架之初应当清楚必须清楚的事项，在做企业框架之前，这些思想准备工作务必先行。
自然，淘宝也需要有量体裁衣的一套框架。这个框架使命是如此浓墨重彩，却也容易让人迷失其中。团队协作模式、万行代码的管理机制、模块的解耦和复用、对后端工程师的友好程度、外加一套完整和谐的视觉规范、以及大量精雕细琢的widgets，即复杂多变，又清晰易用，这才真正考验框架设计师的能力和水平。说到这里不得不提及Yahoo在这方面的出色工作，堪称教科书式的典范，使用YUI作为“范库”，拥有yloader、combo、phploader、yapache、compressor tools、ypatterns、以及ydn，淘宝有了一个不错的榜样，照着这条路走就成了。
如何量身打造一个前端框架 续篇
[ view entry ] ( 1063 views ) | permalink |
( 3 / 175 )我们大概已经很熟悉yui和dojo的动态加载脚本机制，即只要预先定义好模块依赖树，在启动中指定模块名称，yui就会动态加载脚本到页面中，而无需在手写一大堆script标签来引入外部脚本，实际上，yui中add模块所带的第四个参数配置项，也给出了另外一种加载脚本的机制，即只需在YUI().use()时，引用模块名称，模块的依赖只需在模块代码中指定，比如，在一个script block中：
YUI.add('mojo-a',function(Y){
//模块代码
},'',{requires:['anim','node']});
YUI().use('mojo-a',function(Y){
//启动开始
});这段代码是可以正确运行的，也就是说，YUI().use()的主控逻辑只要知道自己依赖模块A即可，模块A依赖的node和anim则不再主控逻辑的视野范围内。这是一个相对超前的精妙设计，虽然这种方式依然不如php和python的auto load智能，但从代码易读的角度看，则更适用于门户和sns这些较为复杂的webapp，这也符合yui的设计初衷。
当然，这里需要澄清一点，动态加载（Lazyload）和自动加载（Autoload）是两码事，yui loader属于动态加载（Lazyload），仅将单维度的脚本依赖关系升级为多维度而已，部分减少无必要的代码维护成本，而Autoload纯粹是给初学者搞的一个hack，毕竟，不论是java还是php、perl还是python，都带有大量的库，开发者不可能全都搞清楚这些库和他们的依赖关系，所以就有了Autoload这种安全低效的coding方式，即开发者根本无需知道函数在哪个包中，直接使用即可，当程序执行到这个函数，发现函数不存在并抛出为定义变量的异常，由框架捕捉并处理异常，根据异常消息去加载所需要的模块，加载完毕后恢复现场继续执行。显而易见，Autoload是很安全的，执行效率也很低下，更重要的，模块变的可维护性极差：当需求变更需要改代码的时候，没有预先定义好的模块关系，去代码丛中反推包依赖关系是相当困难的。
在js层面很难实现autoload，瓶颈在于断点现场的保存。实际上，yui已经给出了另一种思路，来让动态加载更加智能一些。比如上一段代码，能不能把YUI.add()这部分抽离到外部脚本中呢？主逻辑只需要知道他要用什么模块，模块的依赖由模块去解决，为什么非要给yuiloader弄一个addmodule，增加了逻辑块之间的耦合。YUI这样做有两个原因，1，combine的需要，2，高质量的代码管理。combine很容易理解，预先定义好模块依赖以便计算模块顺序并拼成一个url，另外，模块依赖可以在全局统一管理，减少初级开发者的粗心造成的代码冗余。yui做出了正确的取舍。
说了半天，既然半自动加载模块的思路已经成型，干嘛不实现一个呢？
简单写了一个sandbox-seed.js，实现了上述的半自动加载脚本的机制。Sandbox沙箱完全模仿YUI。其中Sandbox对外提供“ready”和“add”两种调用，Sandbox.ready()类似YUI().use()，Sandbox.add()类似YUI.add()，和yui最大的不同就是模块依赖树是自动构造的。
demo 1，demo 2熟悉yui的人一看就懂
[ view entry ] ( 778 views ) | permalink |
( 3 / 201 )之前写过一个基于yui3的日历控件，现在将其调整为基于YUI2的版本，yui3和yui2除了在选择器上的不同之外，最大的区别就是自定义事件，yui2的自定义事件比yui3更加简单，理解也更方便，只需要用CustomEvent创建实例即可，而yui3则需要由工厂“发布”事件，从这一点上可以看出yui3和yui2在设计思想上的一些强化：yui3将零散的“CustomEvent”根据其宿主进行归类，一个widget发布的事件只能由widget本身使用，这使得yui3对事件的管理更加内聚，从结构上看，零散事件也被widget隔离开来，方便开发者全局把握widget的开发。此外，yui3的node接口的设计显然承接yui2的elements，表面上是将selector和element柔和到一起，基础接口做了更完善的扩展，这在使用yui3的时候，脑海中会自然形成一个个封装好的格式统一的“节点”。此外，yui2的APIDoc并不是非常完整，有很多隐含的方法需要看源码才能知道。
除了yui2和yui3在自定义事件和node查找上有不同，其他calendar均保持一致，因此，calendar控件的设计思想是和yui无关的。
;)
有兴趣可以看看他们的比较：
基于yui2的日历：
http://tbexample.googlecode.com/svn/tru ... endar.html
基于yui3的日历：
http://tbexample.googlecode.com/svn/tru ... endar.html
平时多注意理解基本的设计模式的原理，做到这些，才能摆脱“库”对自己的限制。
[ view entry ] ( 963 views ) | permalink |
( 3 / 222 )
