原创，转载请注明出处。

今天都在折腾project explorer，主要是在RCP里加入project explorer以后，不能正常显示，同时刷新的时候又清空那个view，非常奇怪。

最后按照eclipse.org的help的指导设置成功，
http://help.eclipse.org/ganymede/index.jsp?topic=/org.eclipse.platform.doc.isv/guide/cnf.htm

主要是要在自己的WorkbenchAdvisor类里面重写的initialize(IWorkbenchConfigurer configurer)的方法。


然后是覆盖getDefaultPageInput方法如下



这次得到的教训就是以后有什么问题首先查询eclipse.org，要不浪费太多时间了。

第4章 准备

准备阶段最重要是关于HTML/CSS和Javascript如何协作的问题。

浏览器初始化顺序是首先脚步，然后是statements，最后是html。

如果在js里面直接引用body里面的element就会报错，最好是把执行脚本放到函数里调用。

一些常见的钩子

id：创建钩子最简单的方法，每个id在文档中只能使用一次。
var x = document.getElementById('hook');

class：可以为一系列的元素初始化相同的行为。

自定义属性：即不属于(X)HTML规范的属性，这是不合法的，但有时为了脚本的方便使用它。

名/值对：即写成如下的形式，然后从className中通过操作字符串获取状态。

准备页面：设置事件处理程序，确定访问者状态，设置访问，产生内容，定义关系(relatedElement)，修改文档结构。

<script>标签

defer属性：表示正在加载中的脚本不包含任何会改变HTML的指令（如document.write）。Explorer仅在页面已经完全加载之后才会执行拥有defer属性的脚本。

XHTML规定包含内容的script标签必须定义成CDATA，它会告诉XML/HTML解释器不要解析这些内容，而是直接送给脚本引擎。

所有的脚本都被注册到HTML的全局对象中，同一个变量可以在多个脚本中使用，且为最后定义的那个。

当浏览器遇到script标签时，发送一个HTTP请求去获取脚本文件，解析其中的脚本，对HTML页面的分析和渲染暂停，直到脚本加载完成。

load事件会在页面完全加载时触发，window.onload = ; 多次设置onload会覆盖之前的设置，需要编写函数在同一个元素上设置多个事件处理程序。

等待load时会因为图片等造成延迟，这个问题很难解决，目前只有Mozilla支持的DOMContentLoaded事件，在文档加载完成后执行，不必等待图片。

第3章 浏览器

每种浏览器都包含一个代码引擎或渲染引擎，它负责解释Web页面上的代码，javascript解释器是其中的一部分。

Netscape4惨败之后，网景公司于1998年创立了Mozilla项目，开发了Gecko引擎，现在它支持着Mozilla, Firefox, Netscape, Camino等浏览器。

Explorer的代码引擎叫做Trident，1999年3月发布的Explorer5.0是第一个支持W3C DOM和XMLHttpRequest的浏览器，但也是最后一个包含了主要Javascript更新的Explorer版本。

Safari于2003年发布，它使用KHTML代码引擎，它是Macintosh平台的默认浏览器。

Opera是一个独立的浏览器，在浏览器大战期间，它没有实现DHTML，现在看来，这是一个相当英明的决定。

4种兼容性问题

不支持：这些出现问题的功能不是“不可或缺”的基础功能，都能够通过对象检测判断，而且浏览器也在努力消除这些问题，如document.sytleSheets来读写整个样式表，目前Safari和Opera也增加了对其的支持。

合理的不同看法：如defer属性对加载脚本的要求，Exploer有独特的理解，幸好这种问题是最少有的。

有意为之的兼容性问题：通常是浏览器大战的遗留问题，也可以通过对象检测来判断，一旦微软着手实现W3C事件标准，最后一批被故意造成的兼容性问题也将得到解决。

浏览器bug：这是由于编程的缺陷造成的不可预见的错误，它是无法解决也是无法衡量的。如Exploer6会被normalize()方法导致崩溃。

浏览器兼容性问题是单纯的生活的事实，它不会轻易消失，应该尽快地习惯它，至少听任它。

在任何情况下都不要先为某一个浏览器写脚本，然后增加其他浏览器的支持。在项目支出就应该解决这些兼容性问题，而不是放在最后。

对象检测

对象检测是避免兼容性问题的最佳助手。它的一般方法是检查想使用的对象，看它们是否存在，如果不存在，就结束函数。（if(!对象)），从技术上说，对象检测是把一个对象转换成一个布尔值。

检查W3C DOM：

对W3C DOM的检测使我们可以总是假设浏览器也支持相关的功能，如appendChild，而省去对它的检查。

事件处理测试：

我们期望未来的版本使用标准，所以对标准的支持应该最先检查，事实上先检查attachEvent，Fx等浏览器会报错。

浏览器检测

为什么浏览器检测行不通？浏览器兼容性模式是不断变化的，今天不支持的属性，明天可能会支持；而且浏览器常常会伪装自己的身份，以便通过浏览器检测。

浏览器检测的军备竞赛

navigator.userAgent中保存了每一个浏览器的识别字符串。1995年前后的Mosaic和Netscape年代中，由于 Netscape的cookie和<center>标签等的支持，服务器端的程序员决定使用浏览器检测来区分两种浏览器，他们检测识别字符串 是否从Mozilla/开始，这给javascript世界带来了不必要的磨难。浏览器厂商被迫将自己的识别字符串变成从Mozilla/开始，即便是 Explorer最初进入市场时也将自己伪装成了Netscape。浏览器大战开始后，Web开发者们做出反应，他们创建了更多的浏览器程序来区分 Netscape和Exploer，而当战争结束时，已经有数不清的网站设置了检测脚本只允许Explorer访问，历史重演了，一些浏览器如 Opera，又不得不修改自己的识别字符串来匹配Explorer，甚至将识别字符串的设置开放给用户。

拆解浏览器字符串

第一个是Mozilla1.7.12，第二个是NT5.1(即XP)的Explorer6.0，第三个是Safari1.3.2，第四个是伪装后的Safari1.3.2。

userAgent：使用navigator.userAgent，而不是navigator.appName和navigator.appVersion。前者尚有一些遵循，后者都是谎言；

Mozilla/：只能证明浏览器是1994年后发布的；

/[version number]：没有意义，每一个现代浏览器都生命是第4版或第5版的Mozilla；

不规则字符串：通常被圆括号包围，包含这非常复杂的缩写；

Opera：唯一支持window.opera属性，可以检测这个对象来判断；

Safari, iCab和Konqueror：不像Opera那样勇于承担风险，它们可以完全地伪装自己；

Gecko：Mozilla识别串通常都会包含Gecko，但不幸Safari等也包含；

MSIE：没有意义，绝大多数的浏览器都包含MSIE；

版本号：Exploer和Opera允许在名字后面找到自己的版本号，而其他浏览器都无效，比如Mozilla的隐藏版本；

操作系统：Windows操作系统都以Win开始，当然这不适用于伪装的串。

(http://www.quirksmode.org/js/detect.html)

浏览器检测的正确使用

当你需要知道访问者的浏览器，如站点统计时，这些检测不会影响脚本逻辑。

当我们用对象检测时需要排除浏览器bug等时，可以将对象检测和浏览器检测一起使用。

调试

Mozilla有最好的错误信息，因此多在Mozilla中调试；

使用return，alert，confirm是不错的方法，复杂的调试可以自己创建一个错误控制台；

将bug报告给浏览器厂商。

第二章 大背景

javascript嵌入在一个还同时使用着HTML和CSS的环境中。

 

2002年，Stuart Langridge提出无侵入脚本编程(unobtrusive scripting)。它代表了向基于CSS的、兼容标准的Web站点的新理论中嵌入Javascript的首次认真的尝试。

它应该是可用的。即给网站带来明确的可用性好处。

它应该是可访问的。如果javascript失效，网页应该依然是可阅读和可理解的。

它应该是容易实现的。Web开发者只需要在页面中引入脚本本身和一个Javascript钩子，脚本就能运行。

它应该是分离的。只存在于自己的.js文件中，而不是散落在HTML中。

 

一个Web页面由如下三个层组成：HTML结构层、CSS表现层、Javascript行为层。

 

表现与结构的分离

所有的表现定义在一个单独的CSS文件中，HTML中不再出现<font>标签和用于表现的表格。一般通过脚本改变className来引用不同的

CSS元素。CSS (display: none)用来表示文档中的某个元素隐藏，也可以通过脚本从文档中删除这个元素。至于采用哪种方式，PPK推荐采用后一种方式。特别是对于form表单的时候，采用第一种方式就会提交很多无用的信息。

 

行为与结构的分离

所有的javascript函数都被放在一个独立.js文件中，然后把它链入所需要它的HTML页面中，HTML移除所有的事件处理程序。

钩子(hook)用来生命“在这里准备部署行为”的ID，它是注册事件处理程序的一种方法。

javascript:伪协议是复杂而肮脏的(<a href="javascript:dosomeaction()">)，应该放到脚步文件中。

 

行为和表现的分离

行为和表现的分离是复杂的，尚没有任何的标准。

当若干元素部署相同的效果时，CSS是有效的，而需要创建相似但不完全相同的效果时，javascript是最有效的方法。

 

可访问性规则

条理分明的HTML，如硬编码的链接必须有href。

产生对脚本用户有意义的内容，如：

一条发送ajax请求的链接可以完全用javascript生成，这样无脚本用户就不会看到href为#的a标签而产生不解；

用javascript来隐藏一段内容，而不是用css，否则无脚本用户将永远看不到那是什么；

判断是否脚本可用，然后跳转到一个无脚本页面时，要用location.replace而不是location.href，这样在后退时不会再返回到有脚本页面，事实上location.href产生了一条历史记录；

针对键盘用户，我们对触发事件的元素增加focus动作；

由于各浏览器都支持（但不完全支持）javascript，因此<noscript>标签就显得没有意义，最好完全不用。

 

第一章：目标

javascript的目标是给Web页面增加一个额外的可用性层。

 

js分为6个部分：javascript核心、BOM(浏览器对象模型)、事件、DOM(文档对象模型)、CSS修改、数据检索(XMLHttpRequest)。

他们的任务：核心使得js成为一门编程语言的基础，控制结构变量函数和对 象；BOM给浏览器窗口下达指令，读取cookie，与其他窗口进行通信；事件找出用户执行的动作，并定义这些动作将触发的函数；DOM学习和改变 HTML文档的结构；CSS学习和改变HTML文档的CSS表现；数据检索从服务器下载新的数据而不刷新页面。

所有的脚本都是用核心语言、事件和DOM：等待行动，并更新页面。

 

ECMA(欧洲计算机制造联合协会)对javascript核心进行标准化(ECMA1.5)，这个标准应用到flash、浏览器、服务器以及其他尚未产生的应用上。

W3C(万维网协会)创建了DOM规范，它也包括事件处理和CSS修改的内容。微软仍然没有实现W3C的事件规范，却使用它自己专有的事件模型。

WHAT-WG(Web超文本应用技术工作组)正为BOM标准而工作。

数据检索使用的则是微软的事实标准，W3C为数据检索推出了XMLHttpRequest规范的第一部草案。

 

<script标签中允许在language="javascript1.2"中指定版本号，但自1.2版本开始Netscape和Explorer 4都宣称支持，因此设置版本号没有意义，事实上根本不需要这个属性。

 

js遵循严格的安全规范

不允许访问宿主计算机：不能读写除cookie外的文件系统

同源策略：两个窗口的页面的Web域名必须相同，才允许跨窗口通信。同子域下可以通过设置相同的document.domain(必须设置为真实域名的一部分)进行通信。

其他限制：不能读取历史对象的属性(当可以在历史中后退)；不能设置文件上传表单域的值；试图关闭窗口时会询问用户；不允许打开一个小于100x100或处于屏幕之外或没有标题栏的新窗口。

 

javascript的历史

创始人Brendan Eich当时在Netscape工作，js公开的历史从1996.3的Netscape2发布开始。

Eich最初的目标是为Web开发者提供一种简单的方式为页面增加一些交互，这些 脚本从其他页面复制过来并稍作调整就可以使用。最初命名为LiveScript。但Netscape出于市场的考虑选取了一个与当时流行的Java相似的 一个名字，并仓促地要求Eich“使这个语言看起来想Java”，从而误导人们将js视为轻量级的Java版本，看成一个可以拿来搬弄技巧而不值得引起严 谨的程序员注意的轻巧的脚本语言。

 

第一瘦时期

早期的日子里，浏览器是一个瘦客户端，表单验证和鼠标滑过的效果是令人惊艳的，但它们不允许在客户端大量进行交互，用户被迫与服务端交互。

1996~1999间Netscape与微软的浏览器大战开始，双方都推出自己的 第4版，为争夺CSS规范各不相让。两个浏览器厂商都让javascript可以控制这些CSS声明，于是就可以使用position:absolute 创建一个“层”，然后通过持续地改变top和left似的它在屏幕上移动，这才叫酷！这些小伎俩被冠以DHTML为人所知，即通过javascript来 改变css属性。

为此双方都推出了自己专有的DOM（又称过渡DOM，介于Netscap3DOM和W3CDOM之间），Netscape4支持document.layers，而Explorer支持document.all。

 

第一个胖阶段

有了这些新特性，客户端增加大量的互动：动画、隐藏和其他视觉效果，javascript的目标转向技术，而不是可用性，js进入胖阶段。

微软在1999年发布Explorer5，相当好地支持了CSS和新的W3CDOM标准。尽管公司和Web开发者尽力挽救，Netscape4还是灭亡了，差不多同一时间，js的第一个胖阶段结束，人们发现的不过是少量的javascript和大量的空话。

CSS变革开始。

 

第二个瘦阶段

浏览器大战接近尾声的时候，Web开发者们厌倦了大量的编程和变通做法，极度地想从头开始。CSS，而不是javascript，给了他们最好的机会来完全突破过去的束缚。

大概从2003年开始，一部分先锋开始用一种深受CSS革命理念影响的新方式写javascript，javascript第一次深深地潜入到全面的Web开发理论中去，而可访问性问题终于被认识到并着手解决。

无侵入脚本编程提出，但并没有立即征服世界。

 

第二个胖阶段

从服务器端悄悄地载入小块的数据，唤醒了沉睡多年的技术构思和可用性观 念，Jesse James Garrett的文章《Ajax：Web应用程序的新方法》开创了Ajax时代，javascript的用途又一次被重新定义，传统web开发者创建的是 瘦的可访问的乱糟糟的js代码，而来自服务端开发的“资深程序员们”创建的是面向对象的，胖的，可访问性差的ajax客户端。焦点又被集中在技术方面，可 用性及为什么要用ajax仍很少被关注，臃肿的库(即框架）与日俱增。

所幸人们都开始同意并遵循已经存在的标准。

 

2006.5数据显示，目前共有至少134中Ajax框架，我个人认为这股热潮已经到达了顶峰，有谁需要134种程序去做本质上是一样的事呢？

javascript将调整回瘦阶段，那时它的用途也将再次被重新定义，当然某个时期第三个瘦阶段结束后会迎来第三个胖阶段.. 从根本上，这种情况只有当每个人都只认同唯一的javascript用途时才会被打破。