就算碎成粉末

deferred延迟队列加载是jquery1.5以后引入的新概念，这里非常自豪的记录下jin版本历程中第一个版本，
差不多在2010年年中我在jin库中就引入了scriptList和scriptReady的概念，意思就是队列加载和队列检测，其实目的跟现在的deferred是一样的，当时主要是为了解决无堵塞队列模式加载js，当时jQuery的版本在1.3到1.4左右尚未有队列的概念，所以这个雏形一直都只有我自己在用，也一直使用无堵塞队列加载来说明这个模式，
后来在2011年不知哪个时期网络上出现被冠名js颗粒化管理这样的概念，就是颗粒化加载js其实跟我的概念差不多但更形象，
jQuery1.5出来时我正被一些琐碎的事缠身没有特意去看新特性直到最近才闲下来研究，jQuery里的deferred队列已经被封装成一个功能相当完整的模块了，比起我自己写的复杂得多，
现在看看jin里面的队列提出点自己认为的不足之处，首先没有做链式调用，其次没有匿名队列概念每个队列都要自己命名，再者队列标识使用简单的boolean值无法做强大的模块扩展，再者状态仅提供队列成功检测没有类似deferred的多状态返回，比如deferred包括“执行状态”“未完成”“已失败”“已完成”。
然针对这个小小的jin库我觉得暂时使用简易的scriptList和scriptReady就够用，它主要还是以JSLoader的目的来使用，它相比RequireJS、SeaJS、LABjs也有一些细微的区别，而且更简单。

其实这个版本更新了很多内容，还有bug修改，可是由于很多内容是从七巧板源码引用的并且该版本尚未想到如何处理我那个有点混乱的drag封装，所以暂时指定为2.1版本。
所有从七巧板源码的引用在注释author中会指明from来源，包括来源版本，如果有经过修改会有update jin的说明。
更新内容包括：
1.封装了个err处理函数，带全局开关，方便开发调试时调用，err函数本身把逻辑体单独提取作为一个回调参数，便于关闭调试功能后连err逻辑运算也一起关闭，可以节约所有的逻辑处理损耗的资源。
2.对getRandom随机种子做了固定长度处理，而且它将不再是一个随机种子，而是一个不重复的随机种子，我们知道随机数也是会重复的，这点很多时候容易被忽略。
3.根据最新的jQuery7源码的改进我也对evalScript做类似调整，具体缘由不清，暂时仅为跟上时代步伐。
4.暂时取消使用arguments.callee作为函数替换，因为在使用过程中发现一个问题，经过监听发现使用arguments.callee在某些情况下不会重写原函数，具体原因还在研究。
5.修改了注释规则和模式，具体请看源码。
6.更多还是自己看源码了，其他大多是小变化或者bug修复。
>>下载请猛击这里

简述：
url：包括url地址栏取值和设置能力
ajax：支持无堵塞js记名队列模式加载，支持队列ready判断，提供标配jsonp支持和可自定义模式的jsonp支持
dragdrop：提供拖曳基础封装和限定模式基础封装
search：提供两种数组暴虐查找模式，单查找返回和多查找返回。
其他：其他额外函数包括type类型判断、un编码与反编码相关等基本函数等请看源码。
>>下载请猛击这里

关于此次下拉菜单应用上做一个简单说明，考虑到操作按钮在系统应用上需要做权限分配问题，那么整个菜单条就必须拥有自由定制能力，可惜yui控件基本上有点死即使做额外扩展都要费好大力气并且二次封装的笨重性和稳定性也是个难题，于是基于jquery再重新构建一个针对性的菜单条模型。
看上去简简单单的下拉菜单其实要处理的事情非常多，本事例代码不长，但考虑的细节非常多很有价值的一次建模。
该版本下拉菜单提供比yui更高的可控性，包括菜单完全自定义，菜单容器模板化，还有宽高加成和容器偏移设置。
>>预览请猛击这里

针对应用型web站点，越来越多的业务逻辑需要在前端做二次处理，最早项目也是使用程序输出json权限表，前端再进行分配，包括导航权限和按钮权限分配。
其结果是，每次模块载入都需要循环遍历dom文档进行权限分配匹对，效率及低，也增加了代码复杂度。
考虑到性能，且权限分配其实没有理由跑前端搅局，第二版设计，使用了动态生成css权限表的模式，完全使用css处理权限分配。
这个改进看来是正确的，我们不需要再对元素进行remove，而且前端本身就是不安全的，隐藏和remove的区别变得微乎其微，但使用remove却要付出巨大的代价。

var newObject=jQuery.extend(true,{},object);
extend本身是合并对象用的，如果想要克隆出全新对象则需要使用一个空对象进行合并，否则可能会出现莫名其妙的问题。
具体缘由懒得追究，总之有了这个方法对象深度克隆真是方便多了，jQuery真是帮大忙了。

>>dataTabel（右键编辑）
>>dataTabel+page（右键编辑）
>>bubbletip

项目需要，虽然系统大部分功能开发还是基于jQuery开发，但对于数据加载这块我的建议却是自己搭建。
所以开始着手，基本的ajax搭建，接口上基本上是模拟jQuery的实现模式，由于是异步请求所以不得不处理的一件事情来了。
如何通过this访问配置对象，如果是普通的模块开发，默认情况下配置对象本身都可以使用this去访问如：
dataTable({container:"demo",callback:function(){alert(this.container);}});
这是可行的，但如果dataTable改成ajax，callback变成了ajax请求完毕后的回调，那么callback就脱离了作用域跳到window作用域下，这时候访问的this就变成了window对象，那么this.container的访问将会失败。
所以这个时候需要使用callback.call(opt);将当前opt配置带入callback即可。
这是经典的this对象处理方式，听说事件监听器的封装也有同样的处理方式。

最近项目中，一个web页面上无数多的a标签绑定的都是ajax页面请求
做完以后，在ff和IE7上测试没有问题，可是拿到ie6底下就发现链接需要点击两下才能发出请求，或者点击单下有时成功发送请求有时候又失败。

立马用httpwatch看了一下数据，发现在IE6下点击请求的时候，返回的状态是aborted（也就请求被中断了）。

后经google几翻搜索，终于找到原因：请求的链接是用的 A 标签，A上同时写了href和onclick事件。对于链接 A 标签而言，当用户鼠标单击的时候，A对象被触发时会首先去执行onclick部分，然后是href，如果是ie6的话，执行onclick，发出http请求，瞬时又执行href，这时ie6就会abort前一个请求。

解决方法就是：直接把onclick事件写在href中：href="javascript:do()"
还有一种解决方案：<a href="javascript:void(0)" onclick="do();return false;">Test</a>
这样是忽略了href部分，这对于通过onclick传递this，或者无法避开a对象时都有用。
所以解决方案中自然包括替换a标签，使用其他标签替代a标签也是办法。

>>预览请猛击这里

自我加入这个团队，这个团队已经成型7个月之久，而对于我来说，我却只是个临时外派人员。
虽然对项目并不熟悉，但乍看下整套系统前端，着实捏了一把冷汗。
之后了解了关于项目进度和人员配伍上的问题，反而让我非常吃惊。
之后我们探讨了很多方面的问题，包括服务器承载，包括人才与项目选型不可不去考虑的人力投入，还有应用与平台化的决策，还有那庞杂又不稳定的需求。
之后还了解到了项目当初选择yui的初衷和理由，再了解下项目展望我不得不考虑说服让老大放弃yui。
因为在交互和体验上他们有了太多美好的愿望和期望，所以排除人力考虑，我希望项目有自己的js框架。
话虽如此，但我们缺少的可不仅仅是架构师这么简单，连基本的有实力的js人员都寥寥无几。
但项目最终还是打算丢弃yui，理由就不说了，我也不是决策者仅仅是个参与者，可能也有我自己的一些偏见。之后我需要自己打包庞大的datatable等控件，这之间还发生很多特别的故事，本身从需求方到项目经理再到我手上这之间已经是三足鼎立了，每个人都有自己的意见和见解，而且很难权衡，这也是每个项目都会遇到的问题。
但每个项目都有符合自己的解决方案，而这里，最让人揪心的是，还有那么多的勾心斗角，对于我这种做技术的人来说，那真的很头痛，我只是不断努力，也只能不断努力。

无堵塞加载的最佳的实践方案有xhr加载和动态scr请求两种，前者有跨域障碍，所以一般我们选择后者。
可能你和我一样自从明白这一点后也开始了无堵塞封装，可惜应用上一直小心翼翼，因为对旧站升级是那样困难重重。
虽然在最初做无堵塞测试的时候已经证实了方案的可行性和可用性问题，可是一应用到真实环境下往往又出现各种慌乱。

从图片中可以发现，js已经完全实现同步队列加载了，可是问题并没有彻底解决，堵塞依然存在，那么堵塞从哪里来，从瀑布图可以很明白的知道堵塞来自我们自己设计的无堵塞队列，所以这就变成了页面堵塞型无堵塞型队列加载了。
我们找到的堵塞位置刚好是文档中间扦插的一个script标签输出的地方，所以很明显，这样的小技巧只是解决了队列本身不堵塞，其他原先存在的问题依旧，所以我们决定给队列的加载增加settimeout使队列彻底分离出文档流。

问题解决了。
这样就豁然开朗了，只要文档线程还未结束，赋值src形式扦插的script又会回到文档线程中，所以即使在这样的js里面出现document.write也不会让页面清空，它只会在一个非常古怪位置上插入write的内容，而且可能每次位置都不同，只要文档线程尚未结束就不会让整个document被write掉，但是如果你是本地测试环境很有可能出现document被write掉的情况，这种情况下文档线程加载很快就完成了，而外部扦插js还来不及跟上文档线程，文档线程就已经结束，这个时候它才是真正的脱离文档线程存在的，所以本地测试环境是不可靠的，src模式跟xhr还是有本质区别的，xhr是完全脱离文档线程的，而src赋值模式，只是一个有可能在一个巧妙的时间点上出现脱离线程的状态。
设计中特地从mmosite站上找了两个国外的链接下来，这样的测试结果瀑布线显得非常直观和明显，同时结论告诉我们，在简单到极致的页面上堵塞会造成的性能损失已经有可能在50%以上，那么复杂的页面和环境下该要翻成几倍的性能损失呢。

很久之前写的一个wengame的人物装备配置组件
接触的第一个相对大的项目，可惜后面敌不过as军团，项目被替换成as了，虽然没用上但还是蛮用心做的。
>>预览效果请猛击这里

实在对offic旗下的ppt使用不来才滋生做这个应用的想法，所以就用js模拟个ppt应用，先解决下燃眉之急，把课程讲完再说。
功能上基本上都是拿之前写好的插件直接应用的，毕竟时间有限，所以只实现了基本的讲解使用，有需要研究的可以玩玩。
其实这个放到站上来预览效果就差很多了，必定没做预加载过程，如果你想看到本地真实效果可以先打开大纲让图片都跑完再去浏览，必定是本地应用我也没必要弄个预加载什么的，觉得意义不大。
主要实现的功能有课题过渡、大纲预览、大纲选题、键盘翻页支持、鼠标翻页支持、翻页按钮拖曳、课题拖动模式支持、课题点睛模式支持（这个虽然很难发现但却是应用中的一大亮点，可以在课件页面上双击进入点睛模式，再次双击退出点睛模式）。
当然还有一些额外需求由于时间关系没加进来，比如当前位置cookie记录以便刷新之后不会跳回第一篇。 还有对应屏幕变换大小时并没有对页面进行resize监听，其实如果本地应用中加上cookie功能，那么你可以随时随地刷新页面，resize就没那么大必要了，如果为求完美倒可以加进去，但对于应用来说完美的定义分又很多种，代码的简洁也是一种完美，如何平衡，每个人找到的支撑点不同，不做太多评论，我个人有自己的观点和看法，可能你不赞同，但没办法。

纯js面包屑导航，针对性面包屑导航仅提供学习使用。
>>静态模拟预览请猛击这里
>>实际脚本效果预览请猛击这里

09年半吊子时写的js拖曳排序，代码写得比较烂，但设计思路上是正确的，已不提供更新，仅提供学习使用。
>>预览请猛击这里