那么组成框架地重要元素必然是一个个独立地插件，当我们在写一个插件时，要怎样才能让它的扩展性能够满足几乎所有地业务逻辑呢？这是一个十分值得思考的问题。
最近，接触到了一个很优秀的下拉树控件zTree，不得不说真的十分优秀。第一次拿来使用，10分钟便可熟悉所有的API，灵活应用。无论是性能，交互还是扩展性，几乎无可挑剔。我曾2次遍历过其中的所有代码，从中受益匪浅，同时也渐渐养成了自己写扩展性插件的一个习惯，当然肯定还有很多不足的地方，毕竟自己的框架写给自己用，用起来不爽就绝对存在不足的地方。下面就来和大家一起探讨下到底有哪些值得我们学习的地方吧：
- 规范的API接口函数和属性配置。
大大降低了API使用的学习成本。比如所有事件类函数统一on开头，每种事件都有对应的onBefore(事件发生前)，on(事件发生时)，onAfter(事件发生后)三种。属性配置也有一定命名规范，is开头表示“是否是”，has开头表示“是否有/存在”等等。 - 有意义的传参与返回值。
这点也很重要，许多人写js的函数时，喜欢一个函数写到底，没有返回值也没有参数传递，其实这是比较糟糕的。曾经我也不以为然，后来发现其实这样的一个function和把代码写在调用function的地方几乎没有什么差别，唯一的区别顶多就是看着清爽了或者可以被继承下扩展什么的。实际上这样的function，在被不熟悉这段代码的人来使用是很不爽的。多一个有意义的返回值，比如Boolean类型，返回这个函数操作是否有成功执行等等；多几个参数传递进函数，这样才能感觉到这个函数是真的在处理一些特定的数据，而传递的参数也可以让我们更快的理解这个函数做了怎么样的数据处理。 - 错误的英文单词。
俩字：“杜绝”。(每个coder都是艺术家，我们不容许有瑕疵) - 区分private和public。开放出来的API函数最好都相对集中地写在一起，而私有地一些方法地命名尽量区分开来，比如前面加“下划线”等。
- 精简的注释。注释不是写给自己看的，一个产品地代码有80%地可能，开发者和维护者不是同一个人，为了降低成本，作为开发者我们需要给维护者一个可维护地环境。就是在需要地地方给予有效地注释。大大增强可读性。
- css的规范使用。
很多人都忽视css，覆盖和权重问题经常让我们无法得到自己想要的效果。很多时候，觉得只要当前的页面看的过去就认为css没有问题，确实如此。但是写框架类的插件就不能够这样去思考问题，css也会污染全局，仅仅通过特有的类名是不够的。比较好的方法，就是比如我们写一个下拉树控件，下拉树有个基础类是fr-combotree。那么我们所有下拉树的css都统一用.fr-combotree开头，然后一层层向下选择。这样就可以有效的避免互相影响。 - 时间复杂度。
最大只能O(n²)，尽量优化成O(n)或者O(logn)，超过肯定有问题。 - API文档。
十分重要，任何一个优秀框架的必备品。当我们大致写完一个粗糙的框架后，我们就会希望有一份较为完美的doc文档，方便查阅。推荐ExtJs的JsDuck。 - IE兼容。
框架的兼容性是很多企业级应用开发所选择的重要依据。 - 性能优化。
web端的性能也是需要重视的，不然会严重影响到用户体验。可参考：http://115.29.194.184/?p=311
下面针对IE6及IE6以上的兼容的注意点做一些总结：
- css不要使用伪类。只有a标签可以使用:hover，:link，:active，:visited。
- 使用动画效果务必考虑兼容问题。slideDown slideUp fadeIn fadeOut可以考虑使用。
- new Date函数，只能使用 new Date(年,月,日,时,分,秒)或new Date(毫秒)
- 不要使用String[index]方法，应该使用 String.charAt(index)
- $(‘<form/>’)的写法改为$(‘<form></form>’)
- .text()和.html()的区别使用，不要取DOM的text或者html来给控件赋值，因为text()会合并空格，不准确。
- IE6下字过长显示省略号overflow必须和width连用，可参考：http://115.29.194.184/?p=107
- display: inline-block IE8，有些可以采用display: inline和zoom:1解决
- 图片透明问题。可参考http://115.29.194.184/?p=98
- 只能使用HTML3.2及其以下的实体字符
