• 基本类型的常见扩展：原生的javascript对象API往往在现实中不够用，比如常见的Array.indexOf/remove/each，Date.parse/format，不管是怎么封装都需要这类方法
• DOM操作常见方法：DOM节点增删改查，CSS selector，DOMReady，contains，add/remove/toggleClass，屏蔽浏览器之间的操作差异。不多说，人人都熟。
• 一套浏览器检测机制：以前大家都倾向于做浏览器类型和版本的检测，现在倾向于做浏览器的特性检测，这样更有实际用处。
• Ajax的封装，对于组件库来讲可无。毕竟组件库本身的实现不太会用得上Ajax。

• 事件机制都无一例外的是基于第三方观察者或者叫做沙箱(Sandbox)实现。
• 事件机制更深的功能是提供一个模块的通信机制。
• 对于组件库，组件实例之间的通信更加重要，组件实例之间最好不要存在相互引用的关系，互相不能感知对方的存在，有了事件机制，可以通过第三方有效的通知组件实例，减少组件实例间的耦合。

• 该组件继承自哪些组件或者基础类，或者依赖于那些类？
• 组件实例的管理方式，因为每个组件实例都需要在一个容器中统一存放，理想的的存放模型应该是树形的，在内存中存在类似DOM树一样的组件对象树，是否可以通过类名找到相关实例，根据ID获取实例，获取子实例，父实例，父/子实例之间的通信父实例的resize是否能通知容器内的实例resize。
• 插件机制：作为一个非常重要的扩展机制，插件能有效的解决组件间的复用部分，通常这部分会叫做行为(behavior)，对于组件不能提供的甚至是个性化的功能，有没有提供有效的，足够多的扩展点。
• 提供怎样的实例化方式？ new XXX() ?? 还是类似DOM的操作方式appendInstance??甚至有类似jq这种链式。我更觉得应该使用appendInstance的方式，这样能更加有效的体现组件示例间的父/子关系。就像DOM操作一样，最终组件实例也是树形结构，如果我们直接new XXX() 这种方式，其实相当于声明了一个游离态的 DOM节点。实际我写代码的时候发现要管理这些组件实例也是比较麻烦的地方，试想一个页面如果有多个组件实例，需要声明多少个实例变量，或者申明多少个对象去存放这些实例。
• 组件提供的API，一个组件对外暴露的API会包括初始构造方法，公共方法(method)，事件(event)，对于event，提供怎样的eventData也非常重要。

• 模块本身的定义，注册，直接影响一个组件的代码模型，一个组件是一个模块。
• 模块的依赖申明以及追朔机制：就像前面提到的，依赖于那些类，css文件，资源，数据。不仅仅需要声明，还应该可追朔，依赖的父类，也能找到父类本身所依赖的资源，这样为按需部署打包，在线调试提供居多方便。
• 加载机制：因为在开发阶段要么放一个整个组件库代码，要么是通过一个加载器按需加载，到了线上希望只部署引用到了模块组件，这样可以减少实际部署的文件大小。加载机制会涉及到浏览器的javascript/css文件的加载，尤其是需要尽可能的并行下载而且按照依赖关系先后执行。包括应用模块，可以方便的通过这种加载机制延迟，按需，按时的加载到页面中。
• 打包部署机制：由于依赖可追朔，这样实际项目中用到的那些组件可以分析出来，最终可以根据实际使用到的情况打包出适合大小的组件库，减小冗余包的存在。
• 模块间的通信机制，由于模块减轻耦合甚至是独自孤立存在，组件之间的通信就非常重要，比如通常一个页面上面的菜单组件实例点击需要触发下面组件的更新。如果直接监听菜单事件去更新下面的组件，也许菜单是每个页面都有。但是下面的组件不是每个页面都有，这样的事件监听就显然耦合较重，互相依赖对方的存在。如果菜单点击这是告诉第三方我被点击了。下面的组件只去监听第三方的事件，这样的代码思路明显要好过很多。

• css Expression:不仅IE only，更重要是CSS中写javascript这个风格不对，难以维护。
• javascript直接修改style.xxx='xx'。能写成css class的最好都写成css class。
• html中直接写onxxx="foo()"，没有人能保证foo方法存在不被修改。

• 测试用例：通用组件库是一个庞大的工程，也许牵一发动全身，不知道哪个API的变动会影响多少调用者，有充足的单侧用例，一定程度上能保证整个组件库的稳定性。
• 粒度：粒度是一个很值得思考的问题，其实html的标签可以当做是一个小的组件，只是因为粒度很小，要完成一个复杂的应用，有很多的可复用组件都需要用到大片大片的重复html片段。另外一个极端，我们我们把整个页面都写成一个组件，显然没有复用性，跟没封装一样。所以选择一个合适的组件粒度，一个组件完成特定的功能，有利于搭建出有想象力的应用。
• 一致性：需要有很好的代码规范和约定。才能保证API的一致性，用户也会理所当然的想到怎样用API，降低学习成本，一个最常见的例子就事件监听的参数，建议统一为(eventObject,eventData)。
• 文档&Demo:这个不用多说，没有文档和demo的东西没有人去看代码怎么使用。
• 性能：DOM操作是组件库的性能杀手，高效的DOM操作尤其重要，事件监听也是非常耗时的，建议能采用代理的都用父节点来代理。
• 资源释放：组件的资源，引用是否能完全释放？尤其是开发SPA，组件的资源内存释放就非常重要了。

<script type="text/javascript">
function autoheight(){
this.height= this.scrollHeight+this.height+"px";
}
</script>
<textarea id="" rows="" cols="" onpropertychange="autoheight();" oninput="autoheight()" style="overflow:hidden;"></textarea>

这个代码我没有运行，因为一边写就发现不对劲，在propertychange函数中改变property会再次触发propertychange事件，结果就可想而知了。stack overflow。

所以需要换一种思路，新建一个textarea，将同样大的文本放到属性一样的textarea中计算其高度，然后把高度设置到目标textarea中。

搞清楚原理其实就简单多了。要捕捉textarea的change事件在IE下可以使用propertychange,在!IE下可以使用input。

一些textarea资料做参考：

1. textarea 的一些小技巧 http://css-tricks.com/textarea-tricks/
2. 本文的直接资料来源：http://www.planeart.cn/?p=1489

<script type="text/javascript">
window.onbeforeunload=function()
{
    alert("onbeforeunload event");
    //return false;
}
</script>
<a href="#" onclick="return true;">测试1</a><br/>
<a href="javascript:void(0)" onclick="return true;">测试2</a><br/>
<a href="javascript:void(0)" onclick="return false;">测试3</a><br/>
<a href="javascript:void(alert('test 4.'))" onclick="return true;">测试4</a><br/>
<a href="javascript:void(alert('test 5.'))" onclick="return false;">测试5</a><br/>

IE下,"测试4"，"测试5"会触发window.onbeforeunload事件。这是因为，点击事件触发的时候（调用顺序：onclick->window.onbeforeunload->href）。

实际使用的时候还是尽量避免使用javascript:void(0)这样的写法,可以使用 <a href="###"></a>可以防止锚点，但是如果已经写了。可以用jQuery的live方法解决：

使用live方法对于新增的<a href="javascript:void(0)"></a>仍有效，使用例如jQuery datepick会动态的生成很多这样a标签，使用上述方法可以很好的解决这个问题

问题一：要不要采用javascript框架？

我刚到公司的时候，我们的技术架构师是不同意使用javascript 框架。理由很多，javascript 没有得到应有的重视是主要的原因，他一直强调我们做的是应用系统。所以他只在网上找到几个js放在项目下面，然后页面上很乱，要写一颗树展现真是麻烦又麻烦。而且大家的javascript水平都很一般，基本只是稍微了解一点。用的最多的还是数据校验，写的方法还是document.form1.formname,document.add['id']之类的写法。这让我这个天天关注界面的技术人员(冒昧自称技术人员，其实只是在界面层上有点研究而已)真是抓狂。很讽刺的是，为了使用一个小窗口弹出错误信息，把jqeury+ui搬出来。整个项目也只有这么一个地方用到jquery,去年的时候jquery的人气正在攀升。我来了之后，由于自己辈分小，在技术上说不上话，后来大家界面上开发的时候遇到这个那个问题解决不了的时候，大家慢慢的认识到了我的价值。新的项目领导让我负责界面规范这块，公司也想把这个项目做成一个产品。经过很多次“力荐”，我终于说服了大家，我们不能再"IE only" 了。

我认为使用的理由： 一，我们要有兼容各种浏览器的能力，现在新的浏览器大战正在打响，将来的浏览器市场还很难说。在css这方面 我借鉴了ext 的兼容思想，在body标签上加上class "IE IE6",这样我们不要使用hack 去兼容浏览器了。对于javascript上，基本上只有IE和非IE的差别了。主流的javascript框架都提供了很好的浏览器支持。二，用javascript框架的目的是提高开发效率。这与主流的javascript不谋而合。三，web应用正在飞速发展，界面层应用越来越复杂，javascript不在一个校验数据的脚本了，ajax的应用能很好的提升用户体验，有些场合使用ajax，用户操作更加方便。举个很简单的例子，很多的记录需要排序，虽然在数据上来看，只要改变排序值能解决问题，但在界面上，难道要用户去填写排序值，这样用户会觉得很难操作，而用上sortable，这个问题不仅简单，而且操作起来不知道清晰多少。我们从传统的c/s走到b/s不仅是因为b/s 不需要安装，升级容易。还是因为b/s具有更前的表现力。

当然，反对使用javascript框架的理由也很尖锐。一，开发人员的水平很难以掌握现有的javascript框架。二，大家坚持认为，其实现在用的javascript的地方还不是很多。从需求上将屈指可数，tree,borderlayout,grid,calendar。

对此，我提出的想法就是，大家如果觉得难以使用的话，我在javascript框架上做一次封装，降低使用难度。第二个理由更好说，虽然现在使用的地方就那么几个，那好，你能拿出更好的方案么。曾经架构师说，我们希望每一个界面控件都是单独的，能单独使用。当然现在的主流javascript 都是这样的。这样，我就在大家仍用怀疑的眼光注视我的时候开始了javascript框架之旅。

问题二：用哪个javascript框架？

这个问题不是在讨论或者争执哪个好哪个不好，未免大家再又争执，我让他们自己找javascript框架，甚至可以把他们最熟悉的拿出来使用。大伙都说没有时间，这样我也不担心有人说后话了。

我把目前主流的javascript分为三类。

诸如：prototype/jquery/mootools这样的javascript框架，只能是javascript工具。他的优势就是扩展性强，社区支持很好，尤其是jquery

第二类就是：yui/ext/dojo/qooxdoo这样的框架。他们是一套全系列的纯客户端的ui解决方案，使用方便，能满足我们的需要。缺点是入口很高，适用于做富客户端。虽然我们现在的应用还是很多，但是还没有到那个地步。

还有一类就是与服务器端技术结合的ajax框架，他只能叫ajax框架,他基本只做数据交换。事实上只要做一个简单的servlet(j2ee)或者HttpHanlder(.Net)再在客户端加以封装，使用起来也是很方便的。所以这类ajax框架我认为不需要考虑。

在我看来，并不是那个框架绝对的好坏，而是什么样的框架能最好的满足你的需求。

论个人阅历上来讲，三类的多个框架我都知道一二。但是我最喜欢jquery,所以使用了jquery了，他的好处就是轻量级，扩展性强，现有的插件足以满足需要。代码非常简介而且执行效率高。于是我找了一大堆jquery插件。再自己封装城稍微简单的方法。本着不重复发明轮子的原则。很多的界面问题都能解决了。

问题三：真的是那样么？

时至2009,项目完了，到了需要再次封装城产品的时候，麻烦也就来了。我发现虽然jquery插件很多，很全，但是由于是百花齐放，我就不想修改里面的代码。慢慢的使用发现很多插件不是很稳定，像jstree,jquery ui 由于先前用的版本比较低，导致很有的bug自己写一些修正。现在回过头来看那时候做的东西，发现新的版本已经修复了这些功能。而换上新版本的jquery，变化还是蛮多，比如jquery.browser就不推荐使用了，怎么办。

将来。

本文就是在使用jquery之后，发现维护工作量也不小的背景下写下来的。我不知道是不是我当初选择jquery是错误的。是不是应该选择ext 之类的有着更强表现能力，更稳定的框架么？现在的代码还是不是那么理想。由于很多的历史原因，大家还在用ecside ，jscalendar。使用ecside是因为历史原因。使用jscalendar是因为jquery还没有一个日历控件能支持时间的。我一个人的精力有限，而且我很多的时间都在写项目代码(说到底还是领导不重视)。我担心我当时做的决定会对将来造成负面影响。

冒昧发在首页上，真诚的希望大家提出自己的看法，在企业级应用系统上界面层应该怎样做，文中的有些观点如有不对的地方还请大家指教