使用を開始するには、
wgxpath.install.js
ファイルをダウンロードして、ページで有効にしてください。
次に、現在のウィンドウで
document.evaluate
、Xpathナビゲーション関数へのアクセスを提供するページコードでw
gxpath.install()
メソッドを呼び出します。 ライブラリ機能を別のウィンドウに追加する必要がある場合は、
install()
メソッドでこのウィンドウにポインタを渡すだけです。
CSSセレクターの人気が高まっているにもかかわらず、 XPathはHTMLドキュメントの要素を取得するための便利なツールです。 SeleniumやWeb Puppeteerなどのフロントエンドテストアプリケーションで特によく使用されます。 さて、時には、Xpathがページ上の特定の要素にアクセスするための唯一の可能なソリューションである場合があります。
Xpathに出会ったことがない場合は、例を見てください。Google検索結果ページで、式
//li[@class=”g”][3]
はリストの3番目の結果を指します。 これは、ChromeのXpath Viewerプラグインのスクリーンショットから確認できます。
XPathを使用する際の主な問題は、一部のブラウザーでネイティブサポートが不足していることです。 たとえば、IEはHTMLドキュメントのXPathをサポートしていません。 この結果、多くの開発者はJavascriptソリューションの使用を余儀なくされています。 2005年に、GoogleのエンジニアはAJAXSLTライブラリをリリースしました 。これは、正しいXpathを実装しましたが、それほど高速ではありません。 IEでこのライブラリを照会するのはかなり時間がかかりました。
その後、2007年にサイボウズラボグループは別のライブラリであるJavascript-XPathを導入しました。これはAJAXSLTの10倍の速度でした。 多くのテストアプリケーションがそれに切り替え、すべてが素晴らしかったが、長くは続かなかった。 ライブラリはすぐにサポートを失い、バグを修正する人はいませんでした。 それは、 Google Closureに書かれていなかったという事実を考えると、Googleチームである私たちのアプリケーションに統合するのは簡単ではありませんでした。 ライブラリを書き換える必要がありました。
しかし、Google Closureに移植しただけではありません。 ライブラリのパフォーマンスに大きな影響を与えるいくつかの修正を行いました。このバージョンは元のバージョンよりも30％高速に動作します。 さらに、クロージャーコンパイラは25Kに縮小することができました。これはJavascript-XPathよりも40％少ないです。 最後に、新しいコードの構造化とドキュメント化により、ライブラリをさらにサポートするスピードと容易さが確実に得られると確信しています。
それとは別に、このプロジェクトでほとんどの作業を行った2人のGoogleインターン、Michael ZhouとEvan Thomasに感謝します。
GoogleのエンジニアであるGreg DennisとJoon Lee。