================================================================================
Qomolangma OpenProject v1.0

類別??? ：Rich Web Client
關鍵詞? ：JS OOP，JS Framwork, Rich Web Client，RIA，Web Component，
????????? DOM，DTHML，CSS，JavaScript，JScript

項目發起：aimingoo (aim@263.net)
項目團隊：aimingoo, leon(pfzhou@gmail.com)
有貢獻者：JingYu(zjy@cnpack.org)
================================================================================

一、Qomolangma的兼容層設計
~~~~~~~~~~~~~~~~~~

自Qomo Field Test3開始，系統從內核一層開始提供跨(瀏覽器)平臺兼容的能力。Qomo試圖
在不同的瀏覽器上提供相同(或類同)的框架層特性。

Qomo 的兼容層設計跟常見的其它系統并不一致。基于“Qomo是可拆卸可組裝的”這樣一個基
本思想，Qomo實現的兼容層完全可以“象插件一樣增強，或者卸載”。

與一般的系統不同，Qomo基本上是基于IE 6的JScript語言特性來提供的兼容層支撐。也就是
說，如果你向Qomo的兼容層添加一個插件，那么你應該致力于“使第三方瀏覽器表現得跟IE6
一致”。而通常的框架可能會反過來，要求通過兼容層來使得框架表現得跟ECMA-JavaScript
一致。Qomo沒有選擇這樣做，只是因為Qomo原本就更接近于IE，而非其它。

事實上，我要說明的是，讓框架兼容IE，比讓IE上的JScript兼容ECMA更難。因為JScript提供
了很多ECMA不具備的特性。也就是說，Qomo選擇了這種兼容設計，意味著實現一個更強的Java-
Script環境。而不是“讓IE的JScript表現起來更象JavaScript”。

Qomo上的兼容層設計，已經使Qomo可以正常地在IE5.0中運行了。此外，你會發現，Qomo已經在
以下系統上被測試，并得到良好的支持：
? - 以Mozilla(Geckco engine)為內核的瀏覽器環境，例如Firefox
? - Mac上的safari
? - Windows平臺上的IE5.0, IE5.5, IE6.0, IE7.0(beta1&2)

(注: 目前Qomo僅是在JavaScript層面上解決了兼容層問題。對于DOM，Qomo還沒有展開設計。)

二、Qomolangma的兼容層框架
~~~~~~~~~~~~~~~~~~

在Qomo的上一個Field Test中，兼容代碼和unicode相關的解碼是放在system.js中的。但后來
Qomo團隊發現這種設計導致system.js結構非常不清晰，移植性也極差。因此，在Field Test3
之后的版本中，兼容層被抽取出來，用獨立的“兼容層框架”來導入兼容代碼。此外，unicode
相關的解碼被放置到與具體版本相關的“兼容代碼”中。

作為一項參考，Qomo的標準設計環境中是這樣：IE 5.5+瀏覽器。在這種環境下，透過兼容層：
支持：
Geckco engine 1.8.0.1
---------
Mozilla firefox 1.5.0.1以后
? - 沒有unicode解碼特性，因此要求HTML&JS使用UTF-8編碼
? - 使用相對路徑系統(因為瀏覽器對(本地)絕對路徑做出了嚴格的安全限制)

Internet Explorer
---------
IE5, 5.5, 6.0及以后
? - 自動、智能地支持unicode解碼特性。但對于IE5.0使用特殊的解碼方案
? - 使用絕對路徑系統，對路徑/命名空間的識別和支持更準確和完善

Qomolangma通過在system.js中導入Compat/CompatLayer.js來裝載兼容性框架。CompatLayer.js
用于實現：
? - 識別瀏覽器及版本
? - 載入指定版本瀏覽器的兼容代碼

三、Qomolangma如何識別瀏覽器及版本
~~~~~~~~~~~~~~~~~~

當然，大多數瀏覽器相關的書籍都要求分析navigator.userAgent字符串來識別瀏覽器及版本。
但是Qomo沒有(完全)采用這種設計。Qomo使用了一種被稱為“Object Sniffing”的、準確而高
效的技術來實現瀏覽器的識別。在CompatLayer.js頭部的注釋中，你可以看到與之相關的信息。

但是Object Sniffing還是有力所不逮之處。例如識別Firefox v1.5.0與v1.5.0.1。這兩個版本
只修正了一些極細微的bug。因此Object Sniffing是不能識別的。這種情況下，Qomo仍然使用
分析userAgent的技術。為此，Qomo提供了一個內置于CompatLayer.js中的checkit()函數。你
可以看看這個有趣的設計：checkit(v1, v2)返回-1/0/1之一，用于表現v1“小于／等于／大
于”v2。

CompatLayer.js設計了一個checker對象，它的屬性就是瀏覽器版本標識。例如“ie6、ie5”
之類：
? checker = {
??? ie6 : ie && document.compatMode,
??? ie55 : ie && !this.ie6 && [].push,
??? // ...
? }

而后面的表達式是檢測該版本的代碼。

四、Qomolangma中載入指定版本瀏覽器的兼容代碼
~~~~~~~~~~~~~~~~~~

如果checker.<versionTag>條件為真，則一段相應的兼容代碼被自動載入。這段代碼的文件
名約定為“common_<versionTag>.js”。

一個低版本的兼容代碼只需要實現兼容更高版本瀏覽的代碼，最后再載入高版本的兼容層
即可。例如common_ie5.js未尾就載入了common_ie55.js，而后者再載入common_ie6.js。
這樣的設計，使得ie6的環境中不需要載入任何“無關的(非必須的)”兼容代碼。

五、兼容層代碼的特點與問題
~~~~~~~~~~~~~~~~~~

Qomo的兼容層充分地考慮了可擴展性。并為后續代碼中使用這種載入機制提供了可能：在
可以通過$import.get('browser')來取得瀏覽器版本標識“versionTag”。

Qomo兼容層在IE中實現到for IE5.0的兼容，但也付出了巨大的犧牲。這包括：
? - common_ie5.js巨大，且實現不完整
? - 不能使用"<property> in <Object>"語言來檢測屬性是否存在，因為IE5不支持該語法
? - 實現了IE5中的RegExp的$x屬性和相關特性(例如支持函數的String.replace)，但效率
??? 較差，因此IE5的unicode解碼只能采用vbs_JoinBytes()。這也使common_ie6.js出現了
??? 冗余設計。

Qomo通過對IE5兼容的研究，提出了在Mozilla(firefox)、Opera、safari等瀏覽器中實現面
向IE6提供JavaScript兼容特性的通用方法。例如在common_safari.js等中可以看到RegExp的
兼容實現。

Qomo發現了一些與瀏覽器版本或內核引擎相關的嚴重BUG。例如只支持firefox 1.5.0.1以后
版本，并非是Qomo采用了何種特殊的、非ECMA特性的JavaScript語法，而僅僅是因為此前的
Firefox(以及采用早于Geckco 1.8.0.1的Mozilla系列引擎的瀏覽器)存在嚴重的BUG。

同樣，在兼容層中的一些設計，例如common_mozold.js和common_safari.js中對execScript()
的實現。也僅僅是一些未被修正的瀏覽器BUG導致的代碼開銷。

與此相同的，是在IE5上著名的RegExp.lastIndex BUG，這使得common_ie5.js只能用substr()
去分隔字符串，以實現RegExp.replace()。——盡管這是低效的根源。

這些問題與Qomo使用怎樣的兼容方案無關。因此我們只能寄期望于用戶使用更新的、沒有BUG
的瀏覽器。——再或者，忍受bug修補代碼所帶來的效率開銷。:(

轉載于:https://www.cnblogs.com/java0818/archive/2006/03/07/2144568.html

總結

以上是生活随笔為你收集整理的Qomolangma实现篇(三)：兼容层设计的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。