目前Browser的編程接口有兩個(gè)：一個(gè)是Java script，一個(gè)是W3C規(guī)定的DOM接口。前者是Browser親生的，因?yàn)镴ava Script解釋器和瀏覽器的渲染引擎緊密結(jié)合在一起，效率高，效果好。而且從商業(yè)角度考慮，大多數(shù)頁(yè)面離不開(kāi)java script，如果對(duì)其支持的不好，就會(huì)直接影響到Browser的市場(chǎng)前景。后者呢，是W3C制定的標(biāo)準(zhǔn)接口，是Browser抱養(yǎng)的。因此，它的實(shí)現(xiàn)相對(duì)來(lái)說(shuō)并不理想，使用的人也不是很多。從業(yè)務(wù)角度考慮，一個(gè)瀏覽器即使不支持它也不會(huì)受到太大的市場(chǎng)壓力。因此它的質(zhì)量也可想而知的。另外，W3C目前只規(guī)定了HTML的DOM接口，對(duì)于Browser的新特性，比如對(duì)SVG的支持，對(duì)<canvas>標(biāo)記的支持都辦不到。
但是對(duì)于希望把瀏覽器作為應(yīng)用的一個(gè)潛入式組件的開(kāi)發(fā)者而言，DOM接口現(xiàn)狀實(shí)在是一種噩夢(mèng)。
這里，我想到這樣一種解決方案：現(xiàn)在很多java script都在做js-java的橋接，我想能不能反其道而行之，做java-js的adaptor？我的思路是：把JAVA里DOM多數(shù)操作的實(shí)現(xiàn)給替換掉，不是讓它們真的去操縱瀏覽器DOM樹(shù)，而是僅僅生成一段JAVA SCRIPT代碼，當(dāng)遇到set**之類的方法時(shí)，通過(guò)某種途徑執(zhí)行這些java script代碼。這里有兩個(gè)難點(diǎn)：
一是如何得到并操縱瀏覽器的JS引擎。對(duì)于IE，找不到好的辦法；但是對(duì)于Firefox/XULRUNNER，我想是可以的，通過(guò)裝入插件，可以把JS引擎給暴露出來(lái)。
二是如何生成JAVA SCRIPT代碼。這就需要一些編譯的功利了。但是我想既然有那么多閑人有空能去把Swing放到Web容器里；把Eclipse架到Swing上；這個(gè)工作肯定也不是什么難事。
好處是什么？可以讓java程序?qū)g覽器更好的進(jìn)行操控。
附一個(gè)例子：
是用DOM實(shí)現(xiàn)的
http://zhmster.googlepages.com/Dsearch0825_Sample.rar