JP5947888B2

JP5947888B2 - 統合開発環境におけるライブ・ブラウザー・ツーリング

Info

Publication number: JP5947888B2
Application number: JP2014515870A
Authority: JP
Inventors: チャーティアー，ダニエル・ピー; デーヴィス，ジョセフ・エム; ガブアルディ・ゴンザレス，ジョルジ・イー; ジョシ，ヴィシャル・アール; ハーダー，マイケル・ジェイ; バック，マイケル; ファン，アン・ティ−フォン; マンガロール，レシュミ; ジュン，ジョン・イー
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 2011-06-16
Filing date: 2012-06-05
Publication date: 2016-07-06
Anticipated expiration: 2032-06-05
Also published as: KR101908162B1; US20120324422A1; KR20140038459A; WO2012173829A2; CN103597469B; EP2721513B1; CN103597469A; JP2014523567A; WO2012173829A3; US9753699B2; EP2721513A4; EP2721513A2

Description

従来技術

[0001] ワールド・ワイド・ウェブは、近代的な生活の至る所にある一部になっている。対応して、ウェブの開発は、急速に発展しつつある産業となっている。ウェブの開発は、従前のソフトウェア開発とは様々な深い面で異なる。

[0002] 複雑なウェブ・サイトは、様々な異なるページで構成することができ、そのコンテンツは、多くの異なるファイルから生成することができる。コンテンツは、ウェブ開発者によって、無限数の方法でファイル間において分割することができる。ウェブ開発者は、ファイルにおいてコードを書き、このコードがウェブ・サーバーによって処理されブラウザーによって表示されると、ページが得られて、これを閲覧者が見る。ウェブ・サーバーがファイルを処理すると、途中で追加のコンテンツを頻繁に生成する。ウェブ・サーバーによって処理される数行のコードが、最終的なウェブ・ページにおける数百行ものコードの生成に関与することがあり得る。クライアントがウェブ・サーバーに要求を行うと、ウェブ・サーバーは、どのファイルが応答を生成するか判断し、それらを１つのファイルに組み立て、応答をクライアントに返送する。ブラウザーがウェブ・サーバーから受信した文書をブラウザー内にロードした後、ウェブ・ページに対話処理機能(interactive features)を追加するスクリプティング言語が、文書内のコンテンツを追加、削除、または変更することもできる。

[0003] ウェブ処理を行う方法がウェブ開発に影響を及ぼす。ウェブ開発者がウェブ・サイトの一部を変更したいとき、ウェブ開発者は、ウェブ・サイトに関連するウェブ・サーバーにおけるファイルの内どれが、変更しなければならないファイルであるのか知る必要がある。更に、今日では、コードがウェブ・サーバーによって処理されてクライアントが応答を受信するまでは、サーバーがどのコンテンツが生成したのか知る方法がないので、ウェブ開発者は、彼が行おうとする変更の影響を想像することしかできない。スタティック(static)ＨＴＭＬ文書にアプリケーション状機能を追加するために、ＨＴＭＬファイルにおいてスクリプティング言語が頻繁に実行される。スクリプティング言語が実行した後、ブラウザーによって提示される文書は、サーバーから届いたオリジナル文書とは異なる。現在、ブラウザーにおいて選択したエレメントを、ウェブ・サーバーから受信したファイルにマッピングする自動的な方法はない。

[0004] フェッチ・ファイルにおける位置範囲に選択をマッピングし、フェッチ・ファイルにおける位置範囲をソース・ファイルにおける位置範囲にマッピングすることによって、ブラウザーにおける選択を、それを生成したソース・コード・ファイルにおける位置範囲にマッピングすることができる。ソース・ファイルにおける位置範囲を、フェッチ・ファイルにおける位置範囲にマッピングし、フェッチ・ファイルにおける位置範囲をブラウザーにおける選択にマッピングすることによって、ソース・ファイルにおける位置範囲を、ブラウザーにおける選択にマッピングすることができる。

[0005] ブラウザー・ファイルと、ウェブ・サーバーからフェッチしたオリジナル文書との間に関連を作り、ブラウザー選択をブラウザー・ファイルにマッピングし、ブラウザー・ファイルとオリジナル・フェッチ・ファイルとの間の関連を使用してブラウザーにおける選択を、ウェブ・サーバーからフェッチしたオリジナル文書にマッピングすることによって、ブラウザーにおける選択は、フェッチ・ファイルにおける位置範囲にマッピングすることができる。

[0006] フェッチ・ファイルの生成の間にメタデーターを収集することによって、フェッチ・ファイルにおける位置範囲を、フェッチ・ファイルを生成したソース・ファイルにおける位置範囲にマッピングすることができる。メタデーターは、マッピング・テーブルを作るために使用することができ、マッピング・テーブルは、フェッチ・ファイルにおける位置範囲をソース・ファイルにおける位置範囲にマッピングするために使用することができる。また、このマッピング・テーブルは、ソース・ファイルにおける位置範囲を、フェッチ・ファイルにおける位置範囲にマッピングするために使用することもできる。ブラウザー・ファイルとオリジナル・フェッチ・ファイルとの間の関連は、フェッチ・ファイルにおける位置範囲をブラウザーにおける選択にマッピングするために使用することができる。これらのタスクを実行するモジュールをＩＤＥ（統合開発環境）に統合することができる。

[0007] ＨＴＴＰ要求に応答してＨＴＭＬコードをウェブ・サーバーにおいて生成するとき、メタデーター、即ち、ＨＴＭＬコードのスニペットを逆に特定のソース・ファイルにおける特定の位置にマッピングする情報で、コードを拡張する(augment)ことができる。ユーザーがブラウズすることができるウェブ・ページを表すファイルを生成するコードをウェブ・サーバーにおいて実行すると、マッピング情報を、生成したファイルに注入することができ、または他のメカニズムを介してクライアント側ブラウザーに伝えることができる。クライアント側マッピング・モジュールは、ウェブ・サーバーからファイルを受信し、メタデーターを記録し、このメタデーターを使用してマッピング・テーブルを作ることができる。このマッピング・テーブルは、フェッチ・ファイルからの位置範囲を、コンテンツを最初に作ったソース・ファイルにおける対応する位置範囲にマッピングする。クライアント側モジュールは、開発機能と統合され、ＩＤＥ内部で実行するブラウズ体験を提供することができる。開発者にレンダリングされ表示されるものが、ウェブ・サーバー挙動をシミュレーションした解釈ではなく製作ウェブ・サーバーの応答となるように、完全なウェブ・サーバーへのラウンド・トリップ(full round trip)を行うことによって、開発中のページにコンテンツをレンダリングすることができる。

[0008] 文書オブジェクト・モジュール（ＤＯＭ）ツールが、ブラウザー・ページを表現するツリー・データー構造の可視化を提供することができる。カスケード・スタイル・シート（ＣＳＳ：Cascade Style Sheet）ツールが、ルールまたはプロパティを選択し、そのルールまたはプロパティを対応するソース・ファイルにおいて変更することによって、選択したスタイル特性を、そのソース・コード・ファイルにマッピングし、ＨＴＭＬエレメントのスタイル特性に対して考えられる変更を、自動的に永続的にすることを可能にすることができる。また、開発者は、変更をソース・ファイルに適用することなく、ブラウザーにおいて考えられるスタイルの変更を視認することもできる。

[0009] ウェブ・フレームワークが、クライアントにおけるブラウザーからのＨＴＴＰ要求に応答してサーバーからクライアントに送られたマッピング情報を収集することができるように、サーバー側マッピング・モジュールをウェブ・フレームワークと統合することができる。

[0010] この摘要は、詳細な説明の章において以下で更に説明する概念から選択したものを簡略化された形式で紹介するために、設けられている。この摘要は、特許請求する主題の主要な特徴や必須の特徴を特定することを意図するのではなく、特許請求する主題の範囲を限定するために使用されることを意図するのでもない。

[0011] 図面において、
図１は、本明細書において開示する主題の形態にしたがって、ＩＤＥにおいてライブ・ブラウザー・ツーリング(live browser tooling)を設けるシステム１００の一例を示す。図２ａは、本明細書において開示する主題の形態にしたがって、フェッチしたフィルとソース・コード・ファイルとの間でマッピングを行う方法２００の一例を示す。図２ｂは、本明細書において開示する主題にしたがって、ブラウザーとフェッチ・ファイルとの間でマッピングを行う方法２０３の一例を示す。図２ｃは、本明細書において開示する主題にしたがって、ＤＯＭにおける位置範囲と、フェッチ・ファイルにおける位置範囲との間で関連を作る方法２９０の一例を示す。図２ｄは、本明細書において開示する主題による、フェッチ・ファイルのブロック・リストおよびＤＯＭのブロック・リストの一例２３０を示す。図２ｅは、ブラウザーにおける選択からＤＯＭブロック・リストへ、次いでフェッチ・ファイルへのマッピングの一例２７０を示す。図２ｆは、本明細書において開示する主題にしたがって、ＩＤＥにおいてライブ・ブラウザー・ツーリングを設ける方法２４０の一例を示す。図３は、本明細書において開示する主題による計算環境の一例のブロック図である。図４は、本明細書において開示する主題による統合開発環境の一例のブロック図である。

全体像
[0012] ウェブ開発において、（具体的には、MicrosoftのASP.NETのようなフレームワークにおいて）、多くの異なるソース・ファイルを組み合わせて、ユーザーがウェブ上でブラウズすることができるページを形成することができる。例えば、ウェブ・サイトは「ホーム」、「について」(About)、「連絡先」(Contact us)等というように、ウェブ・サイト上のメニュー・バーに複数のページが列挙されている場合がある。このメニュー・バーのコードは、１つのソース・ファイルに存在し、「について」のページは他のソース・ファイルに存在する等という場合がある。ユーザーがこのウェブ・サイトにブラウズするとき、全てのソース・ファイルがユーザーのブラウザーに、例えば、"About.htm"と呼ばれるファイルまたは"Contact.htm"と呼ばれるファイルというような、１つのファイルとして戻っていくことがある。

[0013] ウェブ・サイトにおいて何かを変更したい開発者は、どのファイルに、彼が変更したいエレメントが配置されているのか知らなければならない。多くの場合、変更するファイルを発見することは厄介な作業である。何故なら、例えば、ウェブ・サイトのコンテンツを分割するためにウェブ開発者が選択することができる異なる方法が多数あるからであり、更に情報はソースにコード化される代わりに、データーベースから抽出される可能性があるからである。このため、開発者は「ファイル内で発見する」(find in files)コマンドを手動で実行し、コード全体を見て回り、またはエレメントを発見できるところを思い出すことを頼りにすることを強要されることがある。

[0014] 本明細書において開示する主題の形態によれば、ブラウザーにおいて選択された任意のエレメント、キャラクタ、または位置範囲を、それを生成したソース・コードにマッピングすることができ、ソース・コードにおいて選択された任意の位置範囲を、ブラウザーにおいてソース・コードが生成するものにマッピングすることができる。コンパイルされる開発者ソース・コード（例えば、アセンブリー、バイナリ、エクゼキュータブル等にコンパイルされる）は、コンパイルの間または後の時点において、インストルメント化することができ、コールは、実行されると、コードのスニペットを特定のソース・ファイルにマッピングし、更にソース・ファイルにおける特定の位置にマッピングするメタデーターを送る(emit)。インストルメント化されたコールは、解釈されたソース・コード・ファイルに挿入することができる。ソース・コード・ファイルは、これが解釈されるときに、コードのスニペットを逆に特定のソース・ファイルにマッピングし、更にソース・ファイルにおける特定の位置にマッピングするメタデーターを送る。このメタデーターは、ＨＴＭＬにおける特定の開始位置から特定の終了位置までの情報が、ソース・ファイルにおける特定の開始位置から特定の終了位置までに及ぶことを指定する注入シンボル(injected symbol)を含むことができる。

[0015] ソース・ファイルは、開発者装置において一緒にコンパイルし、サーバーにアップロードして、ユーザーがウェブ・サイトにナビゲートするときに実行されるコードを形成することができる。ウェブ・サイトのあるページがブラウズされたとき、サーバーによってファイルが生成され、ブラウザーによってユーザーのコンピューターにフェッチされる。ユーザーがサーバーにナビゲートすると、サーバーは、実行可能コード内部のメソッドを実行することができる。実行可能コードは、サーバー・コードがＨＴＭＬファイルを構築しブラウザーがこれを取り込むと、ＨＴＭＬファイルの各部分がソース・コードにおけるどこから来るのかを示すメタデーターを収集することができるような方法で、インストルメント化することができる。このように、ブラウザーによってフェッチされたファイルは、ブラウザーがユーザーに表示する必要がないメタデーターを含むことがある。したがって、ブラウザーがＨＴＭＬファイルを取り込むと、ブラウザーがウェブサイト・コンテンツを示すために使用するファイルから、メタデーターを除去することができる。メタデーターは、メモリーにおけるデーター構造に存続することができる。データー構造は、ブラウザー内部における選択を、逆にソース・ファイルにマッピングするために使用することができ、更にソース・ファイルにおける選択を、フェッチ・ファイルにマッピングするために使用することができる。

[00016] ブラウザーの選択を逆にサーバーからフェッチしたＨＴＭＬファイルにマッピングすることは、一層難しくなる。何故なら、Javascript（登録商標）、MicrosoftのJScript（登録商標）、Actionscript、Apple script、VBscript等というようなスクリプティング言語は、ブラウザーにおいて実行することがあるからである。スクリプティング言語は、サーバーからフェッチされたＨＴＭＬを変化させる可能性がある。ＨＴＭＬは、テキスト、リスト、テーブル、およびハイパーリンクを含むスタティック文書を生成する。スクリプティング言語は、ＨＴＭＬをプレゼンテーション言語として使用して、ＨＴＭＬエレメントを追加、削除、変更、および移動することによって、アプリケーション状体験を提供することができる。スクリプティング言語は、これを行うときに、ブラウザーにおいて見られる文書を表すデーター構造を変化させる。本明細書において開示する主題の形態によれば、サーバーから受信したオリジナル・ファイルのコピーを維持することができる。このオリジナル・ファイルにおける単語およびエレメントに識別子を割り当てることができる。スクリプティング言語が実行すると、基礎になるＨＴＭＬに対する変更を、ウェブ・サーバーから受信したオリジナルＨＴＭＬと比較することができる。ＨＴＭＬファイルのブロック・リストおよびＤＯＭのブロック・リストを作ることができ、同一のブロックは同一の識別子を有するので、データー構造においてあるエレメントが、スクリプティング言語の実行の結果移動した場合でも、そのエレメントを、ウェブ・サーバーから受信したオリジナルＨＴＭＬにマッピングすることができる。スクリプティング言語が文書を変更すると、ブラウザーにおけるユーザーの選択を、フェッチしたオリジナル・ファイルにマッピングすることを可能にするために、差分アルゴリズム(differencing algorithm)を実行することができる。

[0017] 本明細書において説明する特徴を組み合わせると、ブラウザーにおける選択を、ソース・コードにおける対応する位置にマッピングすることが可能になる。ソース・コードの選択は、そのソース・コードの選択が最終的にブラウザーにおいて生成するものに、逆にマッピングすることができる。即ち、ブラウザーにおける選択から開発者の装置におけるソース・ファイルのマッピングおよびその逆の組み合わせによって、ユーザーがエレメントを選択する行為によって、開発者が、ウェブ・ページにおけるエレメントのソース・コード・ファイルにアクセスすることを可能にする。例えば、開発者がウェブ・サイトの連絡先ページにおける電話番号を変更したいと仮定する。開発者はＩＤＥを開き、クライアント・コンピューターにおけるクライアント側ブラウザーにおいて視認コマンド(view command)を使用してブラウザーを呼び出し、ブラウザーを開いて、連絡先ページにナビゲートし、ＤＯＭ（文書オブジェクト・モデル）検査ツールを使用して、連絡先ページにおける電話番号を選択することができる。この連絡先ページのソース・ファイルは、ブラウザー表示に隣接して表示することができるので、このブラウザー・ページを生成するＨＴＭＬコードを、ブラウザーにおけるウェブ・ページと同時に視認することができる。ソース・コードのビュー(view)は、ブラウザーにおける選択に対応するソース・ファイルにおける位置までスクロールすることができる。例えば、クライアント側モジュールは、ユーザーを連絡先ページに、そして連絡先ファイルの正確な位置まで連れていくことができる。この位置に、電話番号がハードコード化されているか、あるいはファイルまたはデーターベースにおいて電話番号にアクセスするコマンドが発見される。ソース・ファイルにおける選択を、フェッチ・ファイルから生成されたブロック・リストにおける位置範囲にマッピングすることによって、ソース・ファイルにおける選択を、ブラウザーにおける位置範囲にマッピングすることができる。フェッチ・ファイルにおける位置範囲は、ソース・ファイルにおける選択を生成に関与したダイナミック・ブラウザー・ファイル（例えば、ＤＯＭ）から生成されたブロック・リストにおける位置範囲にマッピングすることができる。

[0018] ソース・ファイルにおいて電話番号を変更するユーザー入力を受けたことに応答して、このファイルを保存し、サイトを再構築し、コードをサーバーにアップロードすることができる。更に、クライアント側マッピング・モジュールは、ブラウザーにおけるページがソース・コードと一致するかまたは一致しないか、開発者に伝えることができる。（対照的に、既知のブラウザーは、そのブラウザーがファイルの最新バージョンを実行しているかまたはそうでないのかわからない。）画面上に表示される選択肢を選択することによって、表示されたウェブ・ページと対応するソース・ファイルを引き出すことができ、ソース・ファイルの最新バージョンを示すことができる。

[0019] クライアント側マッピング・モジュールは、ＤＯＭ（文書オブジェクト・モデル）ツリー可視化ツールを含むことができる。このツールは、ＨＴＭＬからエレメントを作り、ＨＴＭＬページのエレメントの図式表現を表示することができる。ウェブ・ページの他の形態は、ページが見える様子である。ページが見える様子は、そのスタイルと呼ばれ、そのページで使用される色、サイズ、レイアウト、フォント等を含む。ページのスタイルは、カスケーディング・スタイル・シート（ＣＳＳ）によって決定される。スタイルは、複数の場所において定めることができ、文書におけるいずれかの場所、エレメントの右隣り、別のＣＳＳファイル等が含まれるが、これらに限定されるのではない。本明細書において開示する主題の形態によれば、ブラウザーに関連するＣＳＳツールは、ページにおける特定のエレメントについてスタイリング(styling)を分析することができる。

[0020] 特定のタグ（ＨＴＭＬエレメント）について、ＣＳＳツールは、そのエレメントに適用される全てのスタイルを格子形式で表示することができる。ＣＳＳツールは、色、サイズ、余白、フォント・サイズ、パディング(padding)、太字、イタリック体等を含むスタイリングの形態を、表示されるツール・ペインにおいて、例えば、ブラウザー表示の下に表示することができる。スタイリング値に変更が行われると、そのライブＤＯＭファイルを変更することによって、この変更を直ちにブラウザーに反映することができる。更に、スタイルは、ＣＳＳツールによって表示される格子から、そのエレメントに対してスタイルを定めるソース・ファイルにマッピングすることができる。例えば、特定のソース・ファイルにおける特定のエレメントに対して色が定められる場合、クライアント側マッピング・モジュールは、そのエレメントの色が定められるソース・ファイルの識別を判定することができる。文書またはファイルにおいて特定のスタイルが定められた正確な位置を提示することができる。変更する特性を定めるエレメントのプロパティを選択することによって、または変更する特性を定める規則を選択することによって、クライアント側マッピング・モジュールは、開発者がソース・ファイルを変更することによってその変更を行うことができるソース・ファイルにおける位置を判定し表示することができる。ＣＳＳ規則マッピングは、フェッチしたオリジナル・ファイルにおけるＣＳＳ規則毎に一意の識別子を生成し、これらの一意の識別子を使用してＤＯＭ規則を逆にそのオリジナル・ソースにマッピングすることによって行うことができる。実行時ＵＲＬを開発者装置におけるオリジナル・プロジェクト・パスに関連付けるために、プロジェクト・システムを使用することができる。

[0021] 特定のページを表示するためにブラウザーによって用いられるライブＤＯＭファイルからソース・ファイルへの選択マッピングは、入力をサーバーに送り、出力をサーバーから受信することができる（ここでは、サーバーを経由するラウンド・トリップと呼ぶ）。サーバーではかなりの量の処理が行われる可能性があるので、開発者の変更の成果がどのようなものか判断することは難題であり得る。例えば、ＨＴＭＬコードはある項目をオーダーにおいて定めることができるが、このオーダーがサーバーにおいて処理されるまでは、結果的に作られるページがどのように見えるのか知ることができない。何故なら、いくつの項目がオーダーされたか等というようなサーバーの処理に依存するからである。以前の開発ソフトウェアは、設計ビューを提供し、サーバーがそのサーバー側処理を実行した後に、ブラウザーにおいてファイルがどのように見えることになるか開発コンピューター上でシミュレーションを行おうとしていた。

[0022] 開発コンピューターは通例ライブ・サーバーにおける情報にアクセスできないので、そしてサーバー側処理を実行しないので、開発シミュレーションは、処理がサーバーにおいて行われたときのページの外観に非常に近くない場合が多い。本明細書において開示する主題の形態によれば、ウェブ・サーバーからデーターが要求される。開発ファイルがウェブ・サーバーに送られ、ウェブ・サーバーはこのファイルを処理して、結果を開発装置に戻す。ＨＴＴＰ要求は、開発装置が、実際のカストマー体験に忠実である成果を表示できるように実行することができる。言い換えると、ＩＤＥにおいてブラウザーの現在のページのコンテンツをレンダリングする代わりに、サーバーへの完全なラウンド・トリップを行って、開発者にレンダリングされるものが、ウェブ・ページを見ているユーザーにサーバーが提供するものと同じになるようにする。

[0023] 選択マッピングを行うために、ウェブ・サーバー・コンピューターにおいて生成されたメタデーターに基づいたマッピング・テーブルを作ることができる。このマッピング・テーブルは、ブラウザーからのＨＴＴＰ要求に応答して、クライアントがウェブ・サーバーから受信したファイル（即ち、フェッチ・ファイル）の一部をソース・ファイルにマッピングすることができる。このファイルの各部分は、メタデーターに基づく識別子を、ファイルの各セクションに割り当てることによって特定することができる。ファイルの特定された部分を選択する選択イベントを検出したことに応答して、このファイルの選択された部分を、フェッチした文書に逆にマッピングし、更にソース・ファイルに逆にマッピングすることができ、これによって、ユーザーがサーバーへのラウンド・トリップによってページのコンテンツを取り込み、ライブ・ブラウザーのコンテンツをソース・ファイルにマッピングすることを可能にする。
ＩＤＥにおけるライブ・ブラウザー・ツーリング
[0024] 図１は、本明細書において開示する主題の形態にしたがって、ＩＤＥにおいてライブ・ブラウザー・ツーリング(live browser tooling)を設けるシステム１００の一例を示す。システム１００の全部または一部は、図３に関して以下で説明するコンピューターのような、１つ以上のコンピューターに存在することができる。システム１００は、図４に関して説明するソフトウェア開発コンピューターのような、ソフトウェア開発コンピューターにおいて全体的にまたは部分的に実行することができる。システム１００の全部または一部は、ＩＤＥ１０４のようなＩＤＥ内部で実行することもできる。ＩＤＥ１０４は、図４に関して説明するもののようなＩＤＥとすることができ、または任意の他のＩＤＥとすることもできる。システム１００の全部または一部は、ＩＤＥの外部で実行することができる。システム１００の全部または一部は、プラグインまたはアドオンとして実現することもできる。

[0025] システム１００は、コンピューター１０２のような１つ以上のコンピューターまたは計算デバイスを含むことができ、プロセッサー１４２等のような１つ以上のプロセッサー、メモリー１４４のようなメモリー、およびサーバー・モジュール１０８等のような、ＩＤＥにおけるライブ・ブラウザー・ツーリングをサポートするサーバー側処理に備える１つ以上のサーバー側モジュールを含む。また、システム１００は、コンピューター１０３のような１つ以上のコンピューターまたは計算デバイスを含むこともでき、プロセッサー１４３等のような１つ以上のプロセッサー、メモリー１４５のようなメモリー、およびクライアント・モジュール１１６のような、ＩＤＥにおけるライブ・ブラウザー・ツーリングを設ける１つ以上のクライアント側モジュールを含む。当技術分野において周知の他のコンポーネントも含まれてもよいが、ここでは示されていない。尚、サーバー・モジュール１０８のような１つ以上のサーバー・モジュールをメモリー１４４にロードして、プロセッサー１４２のような１つ以上のプロセッサーに、１つ以上のサーバー側モジュールに帰せられる(attribute)動作を実行させることができることは認められよう。尚、クライアント・モジュール１１６の内１つ以上というような、１つ以上のクライアント側モジュールをメモリー１４５にロードして、プロセッサー１４３のような１つ以上のプロセッサーに、１つ以上のクライアント側モジュールに帰せられる動作を実行させることができることも認められよう。

[0026] コンピューター１０２は、ＨＴＴＰプロトコルを使用してウェブ・ページおよび他の文書をブラウザーに配信するウェブ・サーバー・コンピューターを表すことができる。コンピューター１０２は、ウェブ・フレームワーク１０４のような、１つ以上のウェブ・フレームワークを含むことができる。ウェブ・フレームワーク１０４は、ASP.NET、PHP、PERL、Ruby等のようなウェブ・フレームワークとすることができるが、これらに限定されるのではない。本明細書において開示する主題の形態にしたがってライブ・ブラウザー・ツーリングを提供するシステムのサーバー部は、図１ではサーバー・モジュール１０８等によって表されている。サーバー・モジュール１０８等は、ウェブ・フレームワークに対するプラグインまたはアドインとすることができる。ソース・コード１３２および／またはコンパイルしたコード１３４をサーバー・モジュール１０８等から受信することができ、ＨＴＭＬファイルを生成するために使用することができる。このＨＴＭＬファイルは、ブラウザー１１８のようなブラウザーからのＨＴＴＰ要求に応答して、サーバー・コンピューター１０２からクライアント・コンピューター１０３に送られる。

[0027] サーバー・モジュール１０８は、クライアント・コンピューター１０３のようなクライアント・コンピューターに送られるＨＴＭＬファイル（「フェッチ・ファイル」(fetched file)）を生成することができる。サーバー・モジュール１０８は、ソース・ファイルに関する情報を送ることができ、このソース・ファイルからＨＴＭＬファイルのセクションが生成される。ソース・ファイルに関する情報は、クライアント・コンピューターに戻すことができる。例えば、クライアントに送られるＨＴＭＬファイルの中に情報を埋め込むことによって、情報を戻すことができ、または別のファイルにおいて情報を送ることができる。クライアント・コンピューターに送られるＨＴＭＬファイルにメタデーターが含まれるのか、別個に送られるのか、または全く送られないのかは、ウェブ・サイト構成設定、ＨＴＴＰヘッディング情報、クエリー・ストリング情報、フォーム・データー等によって制御することができる。

[0028] サーバー・モジュール１０８は、注釈付きHＴＭＬファイルにおける位置を、ソース・コード・ファイルにおけるソース・コードのセクションと関連付けるメタデーターを生成することができる。例えば、ＸＭＬテーブルを用いて、ソース位置および宛先位置双方を格納することができる。あるいは、トークンを用いて、ＨＴＭＬファイルにおける位置範囲を、ソース・コード・ファイルのセクション等と関連付けることができる。本明細書において開示する主題の一部の形態によれば、サーバー・モジュール１０８は開始トークンおよび終了トークンを生成することができ、これらが合わさって、サーバー・コンピューター１０２によって生成されるＨＴＭＬファイルにおいて、特定のソース・ファイルにおける特定の位置に由来する位置の範囲を定める。尚、トークンのフォーマットは任意の適したフォーマットとすることができることは認められよう。例えば、１つのフォーマットは、$startToken$および$endToken$とすることができる。$startToken$は、考慮対象のＨＴＭＬコードの部分に対するＨＴＭＬファイルにおける開始位置を定めるために使用することができ、$endToken$は、ＨＴＭＬファイルにおける終了位置を定めるために使用することができる。各開始トークン／終了トークンには連番または他の識別子を割り当てて、１対の開始および終了トークンを他の対の開始および終了トークンから区別することができる。

[0029] サーバーが要求ファイル(requested file)を生成し終えた後、コンテキスト・データーを生成することができる。コンテキスト情報を露出するには、任意のデーター構造を使用することができる。コンテキスト・データーを露出する１つの方法は、ＸＭＬフォーマットのデーター構造である。このデーター構造は、マッピング・テーブルとして使用することができ、ＨＴＭＬファイルにおけるセクションを、ソースのセクションと関連付けるために必要なデーターを含む。例えば、ソース・ファイルにおいて、開始および終了トークンによって定められるＨＴＭＬにおける位置の範囲に対応する範囲のテーブルを含むことができる。本明細書において開示する主題の一部の形態によれば、コンテキスト情報は、クライアント・コンピューターに送られるＨＴＭＬファイルの終端に含めることができる。開始および終了トークンの各対は、開始および終了トークンの特定の対を識別する識別子によって識別することができ（例えば、その開始および終了トークンの対に一意の識別子）、ＨＴＭＬファイルにおける位置と、ＨＴＭＬスニペットが生成された元の特定のソース・ファイルにおける位置との間のマッピングを、識別子を照合することによって可能にする。

[0030] 例えば、フェッチ・ファイルにおいて、ソース・ファイルの位置０から開始する１０キャラクタの範囲にマッピングされる、位置５０から開始する１０キャラクタ範囲に対して、この１０キャラクタ範囲に入る、フェッチ・ファイルにおける選択位置５８を、以下のようにして、ソース・ファイルにマッピングすることができる。フェッチした範囲の開始位置を、選択位置から減算することができ、その結果をソース・ファイルにおける範囲の開始位置に加算することができる。この場合、５８−５０＋０＝８となり、８がソース・ファイルにおいて選択された位置となる。同じ演算を、フェッチ・ファイル内において選択した範囲の開始位置および終了位置について実行して、ソース・ファイルにおける対応する範囲の開始および終了を発見することができる。１つのソース位置範囲が、サーバー・コンピューター１０２によって生成されたＨＴＭＬファイルにおける複数の位置範囲にマッピングする可能性もある。例えば、ソース・ファイルが、現在の位置において他のソース・ファイルを含むためのコマンドを含むことができる。

[0031] サーバーによって生成されたＨＴＭＬにおけるコンテンツは、ソース・ファイルにおけるコンテンツと、キャラクタ毎に同一である可能性がある。このタイプのコンテンツを、リテラル・コンテンツ(literal content)と呼ぶ。リテラル・コンテンツは、例えば、ＨＴＭＬであることができる。サーバーによって生成されたＨＴＭＬにおけるコンテンツは、ソース・ファイルにおけるコンテンツとは異なる可能性がある。このタイプのコンテンツを非リテラル・コンテンツ(non-literal content)と呼ぶ。非リテラル・コンテンツは、サーバーによって生成されたＨＴＭＬファイルにおいてＨＴＭＬを生成するために実行されるソース・ファイルにおけるコードとすることができる。サーバーによって生成されるメタデーターは、以下のコンテキスト情報を含むことができる。ソースをフェッチ・ファイルにマッピングするために使用される識別子、ソース・ファイルにおける開始位置、ソース・ファイルにおける終了位置、あるいは代わりに、ソース・ファイルにおける長さ、ソース・ファイルの名称またはパス（出力が作られた元）、コンテンツがリテラル・コンテンツかまたは非リテラル・コンテンツかを示すインディケーター、フェッチ・ファイルにおける開始位置、フェッチ・ファイルにおける終了位置、または代わりに、フェッチ・ファイルにおける長さ。この情報は、フェッチ・ファイルからソース・ファイルへの移動(translation)を可能にする。

[0032] 図２ａは、本明細書において開示する主題の形態にしたがって、ブラウザーおよびソース・コード・ファイル間でマッピングを行う方法２００の一例を示す。図２ａにおいて説明する方法は、図１に関して以上で説明したようなシステムによって実施することができるが、これに限定されるのではない。以下で説明する動作の一部は任意であることができる。以下で説明する動作の一部は、以下で説明するのとは異なるシーケンスで実行することができる。２０１において、ブラウザーはＨＴＴＰ要求を、ウェブ・サーバー・コンピューター１０２のような、ウェブ・サーバーに送って、特定のウェブ・ページを要求することができる。２０２において、サーバー側ブラウザー・モジュールを実行するウェブ・サーバーがＨＴＴＰ要求を受けることができ、２０４において、応答して、ＨＴＭＬファイルおよびマッピング・メタデーターを含む応答を生成することができる。本明細書において開示する主題の一部の形態によれば、生成されたＨＴＭＬファイルは、ＨＴＭＬファイルにおける各出力エレメントの位置範囲を定める注釈を含むことができる。ウェブ・サーバー・コンピューターは、メタデーターを生成することができる。このメタデーターは、ＨＴＭＬファイルにおける各注釈付きエレメントについてのコンテキスト・データーを含むマッピング・テーブルを含む。ウェブ・サーバーは、注釈付きＨＴＭＬファイルおよびメタデーターをクライアントに送ることができる。２０６において、クライアント・ファイルは注釈付きＨＴＭＬファイルおよびメタデーターを受信することができる。メタデーターは、ＨＴＭＬに埋め込むことができ、または別個に送ることもできる。２０８において、メタデーターを用いてデーター構造を生成することができる。このデーター構造は、フェッチ・ファイルとソース・コード・ファイルとの間、およびソース・ファイルとフェッチ・ファイルとの間でマッピングを行うために使用することができる。２１０において、ＨＴＭＬファイルから注釈をはぎ取ることができ、２１２において、結果的に得られたダイナミック・ブラウザー・ファイルを、表示のためにブラウザーに渡すことができる。ダイナミック・ブラウザー・ファイルは、ＤＯＭとして表すことができる。

[0033] コンピューター１０３は、ウェブ・ブラウザー（例えば、ブラウザー１１８）をホストするクライアント・コンピューターを表すことができる。ブラウザー１１８は、任意のブラウザーとすることができ、Mosaic、MicrosoftのInternet Explorer（登録商標）、Mozilla、Netscape、Firefox等を含むがこれらに限定されるのではない。ウェブ・ブラウザーは、ワールド・ワイド・ウェブにおける情報リソースを引き出し、提示し、そしてスキャンする(traverse)ためのソフトウェア・アプリケーションである。情報リソースは、ユニフォーム・リソース識別子（ＵＲＩ）によって特定され、ウェブ・ページ、画像、ビデオ、または他のコンテンツ要素であってもよい。コンピューター１０３は、ソフトウェア開発コンピューターを表すことができる。コンピューター１０３は、ＩＤＥ１１０をホストすることができる。ＩＤＥ１１０は、本明細書において開示する主題の形態によるＩＤＥにおけるライブ・ブラウザー・ツーリングのために、１つ以上のクライアント・モジュール１１６等を含む。１つ以上のクライアント・モジュール１１６は、ブラウザー１１８、マッピング・モジュール１３６、ＤＯＭツリー・ビジュアライザ１６０、ＣＳＳツール１６２、および／またはフィルター１２４を含むことができる。また、システム１００は、以下の内任意のものまたは全てを含むこともできる。マッピング・テーブル１３８、１つ以上のソース・ファイル（図１におけるソース・ファイル１２６に代表される）、フェッチ・ファイル１２８、および／またはライブＤＯＭのようなダイナミック・ブラウザー・ファイル。文書オブジェクト・モデル（ＤＯＭ）は、ＨＴＭＬ、ＸＨＴＭＬ、およびＸＭＬ文書におけるオブジェクトを表しこれらと相互作用する相互プラットフォーム、言語独立表示である。ＤＯＭエレメントは、限定ではなくJScriptのようなスクリプティング言語を含むプログラミング言語によってアドレスおよび操作することができる。ＤＯＭは、任意の方向のナビゲーションをサポートする。即ち、ＤＯＭは、子供からその親、親からその子供、および子供から前の兄弟へのナビゲーションをサポートする。また、コンピューター１０３は、ウェブ・サーバー・コンポーネント（例えば、ウェブ・フレームワーク、およびサーバー・モジュール１０８に類似する１つ以上のサーバー・モジュール）（図示せず）も含むことができる。コンピューター１０２および１０３は、ネットワーク１１４を介して接続することができる。

[0034] ブラウザー１１８は、ＨＴＴＰ要求を、ウェブ・サーバー・コンピューター１０２のようなウェブ・サーバーに送ることができる。あるいは、要求をコンピューター１０３におけるウェブ・サーバーに送ることもできる。ＨＴＴＰ要求は、ウェブ・サイトのページを求める要求とすることができる。要求されるＨＴＭＬファイルは、本明細書で記載するような、注釈付きＨＴＭＬファイルとすることができる。メタデーターは、別個に送ることができ、または注釈付きＨＴＭＬファイル内部に埋め込むことができる。ＨＴＭＬファイル内部における注釈の必要性をなくす追加のメタデーターを供給することができる。ＨＴＴＰ要求を受けたことに応答して、ウェブ・サーバー・コンピューター１０２はＨＴＭＬファイルを生成することができ、このファイルの中に、ＨＴＭＬにおける位置範囲をソース・ファイルにおける対応する位置範囲にマッピングするメタデーターが注入される。注釈付きＨＴＭＬファイルは、クライアント・コンピューター１０３に送ることができる。あるいは、メタデーターを別個のファイルで送ることもできる。クライアント・モジュール１１６の内１つ以上のモジュールが注釈付きＨＴＭＬファイル、フェッチ・ファイル１２８を受信することができ、メタデーターおよび／または注釈をはぎ取ることができ、メタデーターからマッピング・テーブル１３８を構築することができ、メタデーターを用いずにブラウザーにファイルを生成することができる。

[0035] フェッチ・ファイルから生成され、ブラウザーがウェブ・ページを得て表示するために使用するファイルを、ダイナミック・ブラウザー・ファイルと呼び、ＤＯＭ１３０のようなＤＯＭに変換することができる。あるいは、メタデーターを別個に送ることもできる。ＨＴＴＰ要求を受けたことに応答して、サーバー・モジュールはＨＴＭＬファイルおよびメタデーター・ファイルを生成することができ、このファイルにおいて、フェッチ・ファイルにおける各出力エレメントをソース・ファイルにおける対応する位置にマッピングするメタデーターが提供される。ＨＴＭＬファイルおよびメタデーター・ファイルは、クライアント・コンピューター１０３に送ることができる。クライアント・モジュール（１つ以上）１１６は、ＨＴＭＬファイル、（例えば、フェッチ・ファイル１２８）、およびメタデーター・ファイルを受信することができる。マッピング・モジュール１３６は、このメタデーターからマッピング・テーブル１３８を構築することができ、このＨＴＭＬファイルをブラウザーに供給することができる。マッピング・モジュール１３６は、先にもっと詳しく説明したように、識別子を照合することによって、ダイナミック・ブラウザー・ファイルまたはＤＯＭ１３０とソース・ファイル１２６との間で、マッピング・テーブル１３８を使用して、マッピングを行うことができる。ブラウザー１１８は、マッピング・テーブル１３８における情報に基づいて、ブラウザー１１８において表示されているページに対して、ブラウザー表示に隣接して、ソース・コード・ファイル（例えば、ソース・コード・エディター（例えば、ソース・コード・エディター１１９）におけるソース・ファイル）を同時に表示することができる。

[0036] コンピューター１０３は、ＩＤＥ１１０をホストすることができる。ＩＤＥ１１０は、本明細書において開示する主題の形態にしたがって、ブラウザーにおける選択とウェブ・サーバーからのフェッチ・ファイルとの間でマッピングを行う１つ以上のモジュール（例えば、選択マッピング・モジュール１３７）を含む。選択マッピング・モジュール１３７は、フィルタリング・モジュールを含むことができる。あるいは、フィルター１２４のようなフィルタリング・モジュールは、選択マッピング・モジュール１３７に対して外部であることもできる。選択マッピング・モジュール１３７は、差分モジュールを含むことができる。あるいは、差分モジュール１２０のような差分モジュールは、選択マッピング・モジュール１３７に対して外部であることもできる。選択マッピング・モジュール１３７は、ブロック・リスト生成モジュールを含むことができる。あるいは、ブロック・リスト生成モジュール１２２のようなブロック・リスト生成モジュールは、選択マッピング・モジュール１３７に対して外部であることもできる。ＩＤＥ１１０は、ブラウザー１１８、レイアウト・エンジン（図示せず）および／またはブラウザー内にレンダリングされたファイルにおいて実行するスクリプティング言語１５０の内１つ以上を含むことができる。ＩＤＥ１１０は、ソース・コード・エディター１１９のような、ソース・コード・エディターを含むことができる。

[0037] また、システム１００は、以下の内の任意のものまたは全てを含むことができる。フェッチ・ファイル１２８のようなフェッチ・ファイル、ＤＯＭ１３０のようなダイナミック・ブラウザー・ファイル、フェッチ・ファイル・ブロック・リスト１２９のような、フェッチ・ファイルから得られたブロック・リスト、およびＤＯＭブロック・リスト１２７のような、ＤＯＭから得られたブロック・リスト。ブラウザー１１８は、ウェブ・サーバーにウェブ・サイトのページを求める要求（例えば、ＨＴＴＰ要求）を送ることができる。応答して、ブラウザー１１８は、ウェブ・サーバーからウェブ・ページを受信することができる。このウェブ・ページはＨＴＭＬファイルであるとよい。ブラウザー１１８によって受信されたファイルは、フェッチ・ファイル２８としてメモリー１４５に格納することができる。ＨＴＭＬファイルがウェブ・サーバーから受信されると、本明細書において開示する主題の一部の形態にしたがって、フィルター１２４のようなモジュールがＨＴＭＬファイルにおける各エレメントに識別子を割り当てて、異なる各エレメントにそれ自体の識別子が割り当てられるようにすることができる。また、単語にも識別子を割り当てることができる。ＨＴＭＬファイルにおけるエレメントは、ＨＴＭＬ開始タグおよびＨＴＭＬ終了タグの対の存在によって境界が定められる。フィルター１２４は、ＭＩＭＥ型「テキスト」に動作するＭＩＭＥ（多目的インターネット・メール拡張）フィルターとしてもよい。尚、代わりに、スクリプティング言語が実行する前の他の時点で（例えば、ＨＴＭＬファイルがブラウザーにレンダリングされた後）、識別子をＨＴＭＬフィアルにおける各エレメントに割り当ててもよいことは認められよう。

[0038] 識別子は、スクリプティング言語が実行しエレメントが動かされてもまたは変化させられても、ＤＯＭ内のエレメントを、フェッチ・ファイルにおけるエレメントに、そしてその逆にマッピングすることを可能にする。尚、削除されたエレメントをマッピングすることはできないことは認められよう。同様に、ＤＯＭに挿入されたエレメントを、フェッチ・ファイルにおける対応するエレメントにマッピングすることもできない。何故なら、これはフェッチ・ファイルにはないからである。ＨＴＭＬフェッチ・ファイル１２８を解析して、ＤＯＭ１３０のような文書オブジェクト・モデル（ＤＯＭ）を求めることができる。文書オブジェクト・モデル（ＤＯＭ）は、ＨＴＭＬ、ＸＨＴＭＬ、およびＸＭＬ文書におけるオブジェクトを表しこれらと相互作用する相互プラットフォーム、言語独立表示である。ＤＯＭエレメントは、限定ではなくJScriptのようなスクリプティング言語を含むプログラミング言語によってアドレスおよび操作することができる。ＤＯＭは、任意の方向のナビゲーションをサポートする。即ち、ＤＯＭは、子供からその親、親からその子供、および子供から前の兄弟へのナビゲーションをサポートする。

[0039] フェッチ・ファイル１２８から作られたＤＯＭ１３０をメモリー１４５に格納することができ、ブラウザー１１８におけるビュー１０４のような、ウェブ・ページのビューを表示するために、レイアウト・エンジンによって使用することができる。ＤＯＭ１３０は、スクリプティング言語の実行によって変更することができる。つまり、ＤＯＭ１３０はときの経過とともに変化することもあり、動的である。ブラウザー１１８が最初にサーバーからフェッチしたウェブ・ページを提示するとき、ビュー１０４は、フェッチ・ファイル１２８に対応する。ＨＴＭＬをＤＯＭに変換することによって、スクリプティング言語がブラウザー１１８内部で実行することが可能になる。JScriptのようなスクリプティング言語が実行することができる。スクリプティング言語が実行すると、スクリプティング言語はＤＯＭを変化させる可能性がある。ＤＯＭが変化すると、ビュー１０４がブラウザーにおいて変化する可能性がある。つまり、スクリプティング言語が実行するとすぐに、フェッチ・ファイルはもはや現在のビューを反映しなくなる。ＤＯＭが変化すると、対応する変化がビュー１０４において反映される。

[0040] ブロック・リスト生成モジュール１２２のようなブロック・リスト生成モジュールは、ＤＯＭ１３０からブロック・リスト（例えば、ＤＯＭブロック・リスト１２７）を生成することができる。ブロック・リスト生成モジュール１２２のようなブロック・リスト生成モジュールは、フェッチ・ファイル１２８からブロック・リスト（例えば、フェッチ・ファイル・ブロック・リスト１２９）を生成することができる。差分モジュール１２０のような差分モジュールは、フェッチ・ファイル・ブロック・リスト１２９およびＤＯＭブロック・リスト１２７に対して実行して、ＤＯＭがもはやフェッチ・ファイルを反映しなくても、ブロック・リスト間でマッピングを行うことができる。差分モジュール１２０によって実行される処理について、以下で更に詳しく説明する。

[0041] つまり、本明細書において開示する主題の形態によれば、スクリプティング言語がブラウザー１１８におけるビュー１０４の基礎となるＤＯＭデーター構造を変化させると、ＤＯＭおよびフェッチ・ファイルのブロック・リストに対して差分アルゴリズムを実行し、ブロック・リストにおけるマッピングの変化に対処することができる。ＤＯＭブロック・リスト１２７は、スクリプティング言語の実行によって行われた変化を反映するように変化することができる。

[0042] 図２ｂは、本明細書において開示する主題の形態にしたがって、ブラウザーにおける選択をウェブ・サーバーからフェッチ・ファイルにマッピングする方法２０３の一例を示す。図２ｂにおいて説明する方法は、図１に関して説明したようなシステムによって実施することができるが、これに限定されるのではない。以下で説明する動作の一部は、任意とすることができる。以下で説明する動作の一部は、以下で説明するのとは異なるシーケンスで実行することができる。

[0043] ２１３において、ブラウザーは、ＨＴＴＰ要求のような要求をウェブ・サーバーに送ることができる。２１４において、ブラウザーは、要求したファイルをウェブ・サーバーから受信することができる。ブラウザーの要求に応答してブラウザーが受信したファイルを、ここでは、フェッチ・ファイルと呼ぶ。フェッチ・ファイルは、ＨＴＭＬファイルとすることができる。フェッチ・ファイルをメモリーにロードすることができる。２１４において、フェッチ・ファイルを受信すると、異なる各エレメントにそれ自体の識別子が割り当てられるように、２１６においてＨＴＭＬファイルにおけるエレメントに識別子を割り当てることができる。ブラウザーによって、ＨＴＭＬファイルをＤＯＭに変換し、レンダリングすることができる。実行中、２１８において、JScriptのようなスクリプティング言語をDOMにおいて実行することができる。スクリプティング言語は、JScriptに限定されるのではない。２２０において、スクリプティング言語は、実行するに連れて、DOMを変化させることがある。２２２において、ブロック識別子を照合することによって、DOMとフェッチ・ファイルとの間の関連を生成することができる。これについては、以下で更に詳しく説明する。２２４において、ブラウザーにおいて表示されている文書の一部を選択するユーザー入力に応答して、この選択をDOMの一部にマッピングすることができる。２２６において、このDOMの一部を、フェッチ・ファイルのセクションにマッピングすることができる。

[0044] 図２ｃは、本明細書において開示する主題の態様にしたがって、DOMにおける位置範囲とフェッチ・ファイルにおける位置範囲との間で関連を作る方法２９０の一例を示す。図２ｃにおいて説明する方法は、図１に関して説明したようなシステムによって実施することができるが、これに限定されるのではない。以下で説明する動作の一部は、任意とすることができる。以下で説明する動作の一部は、以下で説明するのとは異なるシーケンスで実行することができる。

[0045] ２９２において、フェッチ・ファイルにおける各エレメントに、異なる識別子を割り当てることができる。エレメントは、開始タグおよび終了タグの存在によって特定することができる。２９４において、フェッチ・ファイルからブロック・リストを作ることができる。DOMから、他のブロック・リストを作ることができる。フェッチ・ファイル（ＨＴＭＬファイル）に対してブロック・リストを作るために、このファイルを解析することができ、ＨＴＭＬファイルにおいて発見された開始および終了タグ対毎に、ブロックを作ることができる。エレメントに割り当てられた識別子を保存することができる。ブロックは、ＨＴＭＬファイルにおける単語毎に作ることができる。本明細書において開示する主題の一部の形態によれば、単語には、その単語のハッシュである識別子を割り当てることができる。つまり、ＨＴＭＬファイルにおいて特定の単語が１回よりも多く発見された場合、この特定の単語の各出現は同じ識別子を有する。

[0046] ＤＯＭ２９４に対してブロック・リストを作るために、ＤＯＭをＨＴＭＬファイルに変換することができ、フェッチ・ファイルに関して以上で説明したプロセスを使用して、ＤＯＭブロック・リストを生成することができる。あるいは、ＤＯＭツリーを辿ることができ、それによって、以上で説明したようなＤＯＭブロック・リストを作ることができる。２９６において、差分モジュールが、変更ヘッケル差分アルゴリズム(modified Heckel Diffing Algorithm)のような、差分アルゴリズムを２つの作成したブロック・リストに対して実行することができる。この差分アルゴリズムは、ＤＯＭブロック・リストおよびフェッチ・ファイル・ブロック・リストに対して実行することができる。ＨＴＭＬファイルにおける各開始および終了タグを、１つのブロックとして扱うことができる。つまり、ブロックは、フェッチ・ファイルおよびＤＯＭにおける単語毎に、そして開始または終了タグ対毎に作ることができる。同じタグがＨＴＭＬ文書において１回よりも多く使用されることは頻繁にあるので、一意の識別子を各開始タグに割り当てることができる（例えば、フェッチ・ファイルにおける対応するエレメントの属性に、一意の識別子を設定することによって）。単語は、それらのテキストをそれらの識別子として使用し、したがって、同じ単語が文書において１回よりも多く存在する場合、一意ではない。フェッチ・ファイル・ブロックが、ＤＯＭブロックの一意の識別子と一致する一意の識別子を有する場合、２つのブロックは同一であると判断される。これらの関連を記録することができる。テキストの場合のように、フェッチ・ファイル・ブロックが一意でない識別子を有するが、フェッチ・ファイルにおいて関連するブロックに隣接して存在し、一致する識別子を有するブロックが、ＤＯＭにおける対応するブロックに隣接して存在する場合、これら２つのブロックは同じブロックであると判断される。これらの関連を記録することができる。このプロセスをブロック・リストにおいて順方向および逆方向に繰り返し適用することによって、変化しないブロックの一意でない識別子との関連が見いだされる。記録されている関連を使用して、フェッチ・ファイルのブロック・リストとＤＯＭのブロック・リストとの間、およびその逆のマッピングを行う。

[0047] 図２ｄは、フェッチ・ファイルのブロック・リスト（例えば、フェッチ・ファイル・ブロック・リスト２３２）、およびＤＯＭのブロック・リスト（例えば、ＤＯＭブロック・リスト２３４）の一例２３０を示す。各ファイルにおいて同一のブロックは、指定された識別子を使用して、互いに関連付けることができる（例えば、フェッチ・ファイル・ブロック・リスト２３２のｉｄ＝ＡＡＡ２４０によって特定されるブロックは、ＤＯＭブロック／リスト２３４においてｉｄ＝ＡＡＡ２４２によって特定されるブロックにマッピングする）。例えば、図２ｃにおいて、フェッチ・ファイル・ブロック・リスト２３２におけるブロック２３６は、ＤＯＭブロック・リスト２３４におけるブロック２３８と同一である。ブロック２３６をブロック２３８にマッピングすること、およびその逆を行うことができる。何故なら、ブロック２３６の識別子２４０は、ブロック２３８の識別子２４２と同一であるからである。ＤＯＭブロック・リスト２３４におけるブロック２４４は、フェッチ・ファイル・ブロック・リスト２３２におけるブロックにマッピングしない。何故なら、フェッチ・ファイルが受信された後に"<img/>がＤＯＭに追加されたからである。フェッチ・ファイル・ブロック・リスト２３２におけるブロック２４６（"WORLD")ＤＯＭブロック・リスト２３４において類似するブロックを有さない。何故なら、"WORLD"は、フェッチ・ファイルがウェブ・サーバーから受信された後に、ＤＯＭにおいて削除されたからである。

[0048] テキストのブロックには識別子がなくてもよいが（例えば、テキストは属性を有することができないため）、同一の識別子によって特定されたブロックに続く双方のブロック・リストにおけるテキストの特定されていないブロックは同一のブロックであると仮定することによって、ＤＯＭブロック・リストにおけるテキストのブロックは、フェッチ・ファイル・ブロック・リストにおけるテキストのブロックにマッピングすることができる。例えば、フェッチ・ファイル・ブロック・リスト２３２におけるブロック２３６を、ＤＯＭブロック・リストにおけるブロック２３８にマッピングすることができる。何故なら、ブロック２３６における識別子ｉｄ＝ＡＡＡ２４０が、ブロック２３８における識別子ｉｄ＝ＡＡＡ２４２と同一であるからである。

[0049] ＤＯＭのブロック・リストにおけるどのブロックがブラウザーにおける選択に対応するのか判断することによって、ブラウザーにおける文書選択を、ダイナミック・ブラウザー・ファイルのテキストにマッピングすることができる。MicrosoftのInternet Explorer、Mozilla等のようなブラウザーにおいて選択イベントが発生すると、選択されたストリングおよび選択コンテキスト（即ち、ＤＯＭにおける現在の位置）を含むオブジェクトを返すことができる。ブラウザーにおいて行われた選択に対応するＤＯＭブロック・リストにおけるブロックを判定するために、識別子（例えば、ＩＤ＝ｘ）がある開始タグが発見されるまで、ＤＯＭにおける現在の位置からＤＯＭの先頭までのナビゲーションを行うことができる。開始タグが発見されるまでに逆方向スキャニングにおいて見つかったキャラクタを記録することができる。ＤＯＭブロック・リストにおける対応するブロック（即ち、ＩＤ＝ｘのブロック）にアクセスする。選択に対応する位置が見つかるまで、ブロック・リストおよびＤＯＭを順方向にスキャニングする。ＤＯＭブロック・リストとフェッチ・ファイル・ブロック・リストとの間の関連を使用して、フェッチ・ファイルにおける対応する位置にマッピングすることができる。

[0050] 図２ｅは、ブラウザーにおける選択（例えば、選択されたテキスト）からＤＯＭブロック・リストへ、そしてフェッチ・ファイルへのマッピングの一例２７０を示す。ブラウザーによって見られているファイルにおいて、以下のコードが発見されたと仮定する。

ユーザーがビューにおいて単語Helloから２番目の文字「ｌ」を選択したと仮定する（選択２７８）。この選択イベントは、選択されたストリングおよび文書における選択位置を有するオブジェクトを返すことができる。フェッチされた文書にマッピングすることができるIDを含む最初のエレメントが発見されるまで（例えば、ブロック２３７まで）、DOM（例えば、ビュー２７２）における現在の位置２７９から開始して、DOMをスキャニングし、データー構造において左に移動し、図２ｄにおいて上方向に、DOMの先頭まで移動することができる。その途中で見つかったキャラクタを記録することができる（即ち、この例では、"L"、"L"、"E"、"H"、および"<DIV>"を記録することができる）。

[0051] ブロック２３７において開始タグ（ＩＤ＝ＡＡＡ）２８１の識別子を使用して、ＤＯＭブロック・リストにおけるＩＤ＝ＡＡＡ２８３のブロック、即ち、ブロック２８０にアクセスすることができる。ＤＯＭ（ビュー２７２）およびＤＯＭブロック・リスト２７４は双方とも、記録されているキャラクタ"<DIV>"、"H"、 "E"、 "L"、"L"が見つかるまで、順方向にスキャニングされる。ＤＯＭブロック・リスト２７４とフェッチ・ファイル・ブロック・リスト２７６との間の関連を使用して、フェッチ・ファイルにおいて"L"２８４を"L"２８２にマッピングすることができる。

[0052] ブラウザー１１８は、ブラウザーにおいてレンダリングされ開発者に表示されるものが、サーバー行動をシミュレーションした解釈ではなく生産サーバーの応答であるようにサーバーに対する完全なラウンド・トリップを行うことにより、開発中のページにコンテンツをレンダリングすることができる。フェッチ・ファイル１２８がサーバーによって生成されると、コード・メタデーターをクライアント・コンピューターに発信し(emit)送る(send)ことができる。このメタデーターは、フェッチ・ファイル１２８に注入することができ、または別個に送ることができる。フィルター１２４のようなフィルターは、プラガブル・マイン・フィルター(pluggable mine filter)とすることができ、フェッチ・ファイル（例えば、フェッチ・ファイル１２８）からメタデーターを取り除く。サーバー・コンピューター１０２から受信したオリジナル・ファイルは、ブラウザー１１８に埋め込まれているスクリプティング言語１５０のようなスクリプティング言語の実行によって変化させられる可能性がある。

[0053] 文書オブジェクト・モデル（ＤＯＭ）ツール（例えば、ＤＯＭツリー・ビジュアライザ１６０）は、フェッチ・ファイルからブラウザー・ページを表すデーター構造の可視化に備えることができる。カスケード・スタイル・シート（ＣＣＳ）ツール（例えば、ＣＣＳツール１６２）は、選択されたスタイル特性を逆にそのソース・コード・ファイルにマッピングし、規則またはプロパティを選択しこの規則またはプロパティを変更することによって、ＨＴＭＬエレメントのスタイル特性に対して考えられる変化を自動的に永続させることができる。マッピング・ブラウザー・モジュールは、視認された変化を、エレメントの外観に関与するソース・ファイルに自動的にマッピングすることができる。また、開発者は、変更をソース・ファイルに適用することなく、ブラウザーにおいて考えられるスタイル変更を見ることもできる。

[0054] 図２ｆは、本明細書において開示する主題の形態にしたがって、ＩＤＥにおいてダイナミック・ブラウザー・ツーリングを設ける方法２７５の一例を示す。図２において説明する方法は、図１に関して説明したようなシステムによって実施することができるが、これに限定されるのではない。以下で説明する動作の一部は、任意とすることができる。以下で説明する動作の一部は、以下で説明するのとは異なるシーケンスで実行することができる。

[0055] ２４１において、マッピング・ブラウザーは、ウェブ・サーバー１０２のようなウェブ・サーバーに、特定のウェブ・ページを要求するＨＴＴＰ要求を送ることができる。２４３において、サーバー側マッピング・ブラウザー・モジュールを実行するウェブ・サーバーがこのＨＴＴＰ要求を受けることができ、応答して２４５において、ＨＴＭＬファイルを含む応答を生成することができる。生成されたＨＴＭＬファイルは、このＨＴＭＬファイル内における各出力範囲のソース・ファイル位置を示すメタデーターを含むことができる。ウェブ・サーバーは、マッピング・テーブルを含むメタデーターを生成することができる。このマッピング・テーブルは、ＨＴＭＬファイルにおける注釈付き出力範囲毎にコンテキスト・データーを含む。ウェブ・サーバーは、ＨＴＭＬファイルをメタデーターと共にクライアントに送ることができる。２４７において、クライアント側は、このＨＴＭＬファイルをメタデーターと共に受信することができる。２４８において、メタデーターをＨＴＭＬファイルから抽出することができ、フェッチ・ファイルとソース・コード・ファイルとの間、およびソースとフェッチ・ファイルとの間でマッピングを行うために用いることができるデーター構造（例えば、マッピング・テーブル１３８）を生成するためにこのメタデーターを使用することができる。２５０において、メタデーターをＨＴＭＬファイルからはぎ取ることができる。２５２において、結果的に得られたファイルを、表示のためにブラウザーに渡すことができる。結果的に得られたダイナミック・ファイルをＤＯＭに変換することができる。実行中、２５４において、JavaScript（登録商標）のような、しかしこれには限定されないスクリプティング言語をＤＯＭに対して実行することができる。このスクリプティング言語は、それが実行するに連れて、ＤＯＭを変化させる可能性がある。

[0056] ２５８において、オリジナルＨＴＭＬファイル（フェッチ・ファイル）および、ＤＯＭとすることができるダイナミック・ブラウザー・ファイルに対して差分アルゴリズムを実行することによって生成されたブロック識別子を照合することによって、ダイナミック・ブラウザー・ファイルとフェッチ・ファイルとの間の関連を生成することができる。ＨＴＭＬにおける各開始および終了タグは、ブロックとして扱うことができる。つまり、ブロックは、フェッチ・ファイルおよびダイナミック・ブラウザー・ファイルにおける単語毎に、そして開始または終了タグ毎に、作ることができる。ＨＴＭＬ文書では、同じタグが１回よりも多く使用されることが頻繁にあるので、一意の識別子を各開始タグ／終了タグ対に割り当てることができる（例えば、ＤＯＭにおける対応するオブジェクトのプロパティを一意の識別子に設定することによって）。第１ブロック・リストは、フェッチ・ファイルに対して生成することができ、第２ブロック・リストは、ダイナミック・ブラウザー・ファイルに対して生成することができる。フェッチ・ファイルにおける一意のブロックに直接隣接して、同一のブロックがダイナミック・ブラウザー・ファイルにおける対応する一意のブロックの隣りに存在すると判断したことに応答して、これら２つのブロックが同じブロックであると判定される。このプロセスを一意のブロックから順方向および逆方向に繰り返し適用することによって、変化していないブロックのシーケンスが発見される。２つのファイルにおける同一ブロックは、互いにマッピングすることができる。即ち、ダイナミック・ブラウザー・ファイルにおけるブロックを、フェッチ・ファイルに、そしてその逆にマッピングすることができる。２６０において、ブラウザーにおいて表示されている文書の一部を選択するユーザー入力に応答して、この選択をダイナミック・ブラウザー・ファイルの一部にマッピングすることができる。このダイナミック・ブラウザー・ファイルの一部は、フェッチ・ファイルの一部にマッピングすることができる。２６２において、このフェッチ・ファイルの一部は、ソース・ファイルの対応するセクションにマッピングすることができる。
適した計算環境の例
[0057] 本明細書において開示した主題の種々の形態についてコンテキストを規定するために、図３および以下の説明は、本明細書において開示した主題の種々の実施形態を実現することができる、適した計算環境５１０の端的な全体的な説明を行うことを意図している。本明細書において開示した主題は、１つ以上のコンピューターまたは他の計算デバイスによって実行される、プログラム・モジュールのようなコンピューター実行可能命令という一般的なコンテキストで説明されるが、本明細書において開示した主題の一部は、他のプログラム・モジュールとの組み合わせおよび／またはハードウェアおよびソフトウェアの組み合わせでも実現できることは、当業者には認められよう。一般に、プログラム・モジュールは、ルーチン、プログラム、オブジェクト、物理的アイテム(physical artifact)，データー構造等を含み、これらは特定のタスクを実行するか、または特定のデーター型を実装する。通例、プログラム・モジュールの機能は、種々の実施形態における所望に応じて、組み合わせることまたは分散させることができる。計算環境５１は、適した動作環境の一例に過ぎず、本明細書において開示した主題の使用範囲や機能を限定することを意図していない。

[0058] 図３を参照して、コンピューター５１２の形態とした計算デバイスについて説明する。コンピューター５１２は、処理ユニット５１４、システム・メモリー５１６、およびシステム・バス５１８を含むことができる。処理ユニット５１４は、種々の入手可能なプロセッサーの内任意のものとすることができる。デュアル・マイクロプロセッサーおよび他のマルチプロセッサー・アーキテクチャーも、処理ユニット５１４として採用することができる。システム・メモリー５１６は、揮発性メモリー５２０および不揮発性メモリー５２２を含むことができる。不揮発性メモリー５２２は、リード・オンリー・メモリー（ＲＯＭ）、プログラマブルＲＯＭ（ＰＲＯＭ）、電気的プログラマブルＲＯＭ（ＥＰＲＯＭ）、またはフラッシュ・メモリーを含むことができる。揮発性メモリー５２０は、外部キャッシュ・メモリーとして機能することができるランダム・アクセス・メモリー（ＲＡＭ）を含むことができる。システム・バス５１８は、システム・メモリー５１６を含むシステムの物理的アイテム(artifact)を処理ユニット５１４に結合する。システム・バス５１８は、メモリー・バス、メモリー・コントローラー、周辺バス、外部バス、またはローカル・バスを含む、様々なタイプの内任意のものにすることができ、任意の種々の入手可能なバス・アーキテクチャーを使用することもできる。

[0059] コンピューター５１２は、通例、揮発性および不揮発性媒体、リムーバブルおよび非リムーバブル媒体というような、種々のコンピューター読み取り可能媒体を含む。コンピューター記憶媒体は、コンピューター読み取り可能命令、データー構造、プログラム・モジュール、または他のデーターというような情報の格納のための任意の方法または技術で実現することができる。コンピューター記憶媒体には、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュ・メモリーまたは他のメモリー技術、ＣＤＲＯＭ、ディジタル・バーサタイル・ディスク（ＤＶＤ）または他の光ディスク・ストレージ、磁気カセット、磁気テープ、磁気ディスク・ストレージまたは他の磁気記憶デバイス、あるいは所望の情報を格納するために使用することができコンピューター５１２によってアクセスすることができる任意の他の一時的媒体または永続的媒体を含むが、これらに限定されるのではない。

[0060] 尚、図３は、ユーザーとコンピューター・リソースとの間において仲介として機能することができるソフトウェアについて説明することは認められよう。このソフトウェアは、オペレーティング・システム５２８を含むことができる。オペレーティング・システム５２８は、ディスク・ストレージ５２４に格納することができ、コンピューター５１２のリソースを割り当てることができる。ディスク・ストレージ５２４は、インターフェース５２６のような非リムーバブル・メモリー・インターフェースを介してシステム・バス５１２に結合されるハード・ディスク・ドライブであってもよい。システム・アプリケーション５３０は、オペレーティング・システム５２８によるリソースの管理を、システム・メモリー５１６またはディスク・ストレージ５２４のいずれかに格納されているプログラム・モジュール５３２およびプログラム・データー５３４を介して利用する。尚、コンピューターには種々のオペレーティング・システムまたはオペレーティング・システムの組み合わせを実装できることは認められよう。

[0061] ユーザーは、入力デバイス（１つ以上）５３６を介してコマンドまたは情報をコンピューター５１２に入力することができる。入力デバイス５３６は、マウスのようなポインティング・デバイス、トラックボール、スタイラス、タッチ・パッド、キーボード、マイクロフォン等を含むが、これらに限定されるのではない。これらおよびその他の入力デバイスは、システム・バス５１８を通ってインターフェース・ポート（１つ以上）５３８を介して処理ユニット５１４に接続する。インターフェース・ポート（１つ以上）５３８は、シリアル・ポート、パラレル・ポート、ユニバーサル・シリアル・バス（ＵＳＢ）等を表すことができる。出力デバイス（１つ以上）５４０は、入力デバイスと同じタイプのポートを使用することができる。出力アダプター５４２が、特定のアダプターを必要とするモニター、スピーカー、およびプリンターのような一部の出力デバイス５４０があることを例示するために示されている。出力アダプター５４２は、出力デバイス５４０とシステム・バス５１８との間において接続を設けるビデオおよびサウンド・カードを含むが、これに限定されるのではない。リモート・コンピューター（１つ以上）５４４のような他のデバイスおよび／またはシステムまたはデバイスは、入力および出力双方の機能を設けることができる。

[0062] コンピューター５１２は、リモート・コンピューター（１つ以上）５４４のような、１つ以上のリモート・コンピューターへの論理接続を使用するネットワーク接続環境において動作することができる。リモート・コンピューター５４４は、パーソナル・コンピューター、サーバー、ルーター、ネットワークＰＣ、ピア・デバイスまたは他の共通ネットワーク・ノードとすることができ、通例、コンピューター５１２に関して以上で説明したエレメントの多くまたは全てを含むが、図３には、メモリー記憶デバイス５４６だけが図示されている。リモート・コンピューター（１つ以上）５４４は、通信接続（１つ以上）５５０を介して論理的に接続することができる。ネットワーク・インターフェース５４８は、ローカル・エリア・ネットワーク（ＬＡＮ）およびワイド・エリア・ネットワーク（ＷＡＮ）のような通信ネットワークを含むが、他のネットワークを含むのでもよい。通信接続（１つ以上）５５０は、ネットワーク・インターフェース５４８をバス５１８に接続するために採用されるハードウェア／ソフトウェアを指す。通信接続（１つ以上）５５０は、コンピューター５１２に対して内部であっても外部であってもよく、モデム（電話、ケーブル、ＤＳＬ、およびワイヤレス）およびＩＳＤＮアダプター、イーサネット・カードのような内部および外部技術を含むことができる。

[0063] 尚、図示するネットワーク接続は一例に過ぎず、コンピューター間に通信リンクを作る他の手段を使用してもよいことは認められよう。当業者は、コンピューター５１２または他のクライアント・デバイスをコンピューター・ネットワークの一部として配備できることを認めることができよう。これに関して、本明細書において開示した主題は、任意の数のメモリーまたは記憶ユニット、ならびに任意の数の記憶ユニットまたはボリュームに跨がって存在する任意の数のアプリケーションおよびプロセスを有する任意のコンピューター・システムに関連することができる。本明細書において開示した主題の形態は、リモート・ストレージまたはローカル・ストレージを有するネットワーク環境において配備されたサーバー・コンピューターおよびクライアント・コンピューターを備えた環境に適用することもできる。また、本明細書において開示した主題の形態は、プログラミング言語機能、解釈および実行能力を有する、スタンドアロン計算デバイスにも適用することができる。

[0064] 図４は、統合開発環境（ＩＤＥ）６００および共通言語実行時間環境６０２を示す。ＩＤＥ６００は、ユーザー（例えば、開発者、プログラマ、設計者、プログラム検査者など）が、プログラム、１組のプログラム、ウェブ・サイト、ウェブ・アプリケーション、およびウェブ・サービスをコンピューター・システムにおいて設計、コード化、コンパイル、検査、実行、編集、デバッグ、または構築することを可能にするのであるとよい。ソフトウェア・プログラムは、ソース・コード（コンポーネント６１０）を含むことができ、１つ以上のソース・コード言語（例えば、Visual Basic、Visual J#、Ｃ＋＋、Ｃ＃、Ｊ＃、Java Script、ＡＰＬ、ＣＯＢＯＬ、Ｐａｓｃａｌ、Eiffel、Haskell、ＭＬ、Oberon、Perl、Python、Scheme等）で作られる。ＩＤＥ６００は、ネーティブ・コード開発環境を提供することができ、あるいは仮想装置において実行する被管理コード開発(managed code development)を提供することができ、またはその組み合わせを提供することができる。ＩＤＥ６００は、NETフレームワークを使用して、被管理コード開発環境を提供することができる。中間言語コンポーネント６５０は、ソース・コード・コンポーネント６１０およびネーティブ・コード・コンポーネント６１１から、言語特定ソース・コンパイラー６２０を使用して作ることができ、ネーティブ・コード・コンポーネント６１１（例えば、装置実行可能命令）は、アプリケーションを実行するときに、中間言語コンポーネント６５０から、中間言語コンパイラー６６０（例えば、ジャスト・イン・タイム（ＪＩＴ）コンパイラー）を使用して作られる。即ち、ＩＬアプリケーションを実行するとき、実行されながら、コンパイルされて、それが実行されているプラットフォームに適した機械語になることによって、様々なプラットフォームに跨がってコードを移植可能にする。あるいは、他の実施形態では、プログラムをコンパイルして、その意図するプラットフォームに適したネーティブ・コード機械語（図示せず）にすることもできる。

[0065] ユーザーは、既知のソフトウェア・プログラミング技法、ならびに特定のソース言語に関連する特定の論理および構文上の規則にしたがって、ＩＤＥ６００におけるユーザー・インターフェース６４０およびソース・コード・エディター６５１を介して、ソース・コード・コンポーネントを作ることおよび／または編集することができる。その後、ソース・コード・コンポーネント６１０をソース・コンパイラー６２０によってコンパイルすることができ、これによって、アセンブリー６３０のような、プログラムの中間言語表現を作ることができる。アセンブリー６３０は、中間言語コンポーネント６５０およびメタデーター６４２を含むことができる。

アプリケーションの設計は、配備の前に、有効性を検証できるとよい。
[0066] 本明細書において説明した種々の技法は、ハードウェアまたはソフトウェアと合わせて、あるいはしかるべき場合には双方の組み合わせで実現することができる。つまり、本明細書において説明した方法および装置(apparatus)、あるいはそのある種の形態またはその一部は、フロッピー（登録商標）・ディスク、ＣＤ−ＲＯＭ、ハード・ドライブ、または任意の他の装置読み取り可能記憶媒体というような有形媒体に具体化されたプログラム・コード（即ち、命令）の形態をなすことができ、プログラム・コードが、コンピューターのような装置にロードされ実行されると、その装置(machine)が、本明細書において開示した主題の形態を実施する装置(apparatus)となる。本明細書において使用する場合、「装置読み取り可能媒体」という用語は、任意の形態の伝搬信号を供給する（即ち、格納および／または送信する）メカニズムをいずれも除外するように捉えるものとする。プログラマブル・コンピューターにおけるプログラム・コードの実行の場合、計算デバイスは、一般に、プロセッサー、このプロセッサーによって読み取り可能な記憶媒体（揮発性および不揮発性メモリー、および／または記憶エレメントを含む）、少なくとも１つの入力デバイス、および少なくとも１つの出力デバイスを含む。ドメイン特定プログラミング・モデルの形態の作成および／または実現例を、例えば、データー処理ＡＰＩ等の使用によって利用する１つ以上のプログラムを、上位手続き言語またはオブジェクト指向言語で実現し、コンピューター・システムと通信することができる。しかしながら、望ましければ、プログラム（１つ以上）は、アセンブリーまたは機械語で実装することができる。いずれの場合でも、言語は、コンパイル型言語またはインタープリタ型言語であり、ハードウェアの実現例と組み合わせることができる。

[0067] 以上、構造的特徴および／または方法論的動作に特定した言語で本主題について説明したが、添付した特許請求の範囲において定められる主題は、必ずしも以上で説明した具体的な特徴や動作には限定されないことは言うまでもない。逆に、以上で説明した具体的な特徴や動作は、特許請求の範囲を実現する形態例として開示したまでである。

Claims

システムであって、
計算デバイスの少なくとも１つのプロセッサーと、
前記計算デバイスのメモリーと、
前記メモリーにロードされる少なくとも１つのモジュールと、
を含み、前記少なくとも１つのモジュールが前記少なくとも１つのプロセッサーに、
統合開発環境（ＩＤＥ）に含まれたブラウザーにおいて選択を受けるステップであって、前記選択が、ウェブ・サーバーから受けたフェッチ・ファイルからのコンテンツに関連し、前記ＩＤＥが更にソース・コード・エディターを含む、ステップと、
前記フェッチ・ファイルにおいて前記コンテンツを生成したソース・ファイルにおける位置範囲に前記選択をマッピングするステップと、
前記ソース・ファイルに対しなされたユーザー変更を受けるステップであって、変更されたソース・ファイルが前記ユーザー変更にしたがって生成される、ステップと、
前記変更されたソース・ファイルを前記ウェブ・サーバーにアップロードするステップと、
前記変更されたソース・ファイルに基づいて前記ウェブ・サーバーからアップデートされたコンテンツを受けるステップと、
前記ブラウザーにおける前記選択を、前記ソース・コード・エディターにおける前記変更されたソース・ファイルと同時に表示するステップであって、表示される前記変更されたソース・ファイルが、前記ブラウザーにおける前記選択に対応する前記位置範囲までスクロールされる、ステップと、
を行わせ、前記ブラウザーにおける表示された前記選択が前記アップデートされたコンテンツを含む、システム。
請求項１記載のシステムにおいて、前記少なくとも１つのプロセッサーが、前記フェッチ・ファイルにおける位置範囲を、特定のソース・ファイルにおける特定の位置範囲にマッピングするメタデーターを受信し、前記メタデーターが、前記特定のソース・ファイルに対するパスと、前記特定のソース・ファイルにおける開始位置とを含む、システム。
請求項２記載のシステムにおいて、前記少なくとも１つのモジュールが、前記受信したメタデーターからマッピング・テーブルを生成し、前記マッピング・テーブルが、前記フェッチ・ファイルにおける位置範囲を、ソース・ファイルにおける位置範囲にマッピングする、システム。
請求項１記載のシステムにおいて、前記少なくとも１つのモジュールが、更に、
前記ブラウザーにおける前記選択を、ダイナミック・ブラウザー・ファイルのブロック・リストにおける位置範囲にマッピングするステップと、
前記ダイナミック・ブラウザー・ファイルのブロック・リストにおける前記位置範囲を、前記フェッチ・ファイルのブロック・リストにおける位置範囲にマッピングするステップと、
前記フェッチ・ファイルのブロック・リストにおける前記位置範囲を、前記ブラウザーにおいて前記選択を生成した前記ソース・ファイルにおける対応する位置範囲にマッピングするステップと、
を含む、システム。
方法であって、
ソフトウェア開発コンピューターのプロセッサーによって、ウェブ・サーバーから、統合開発環境（ＩＤＥ）に含まれたブラウザーにおけるユーザー選択を受けるステップであって、前記ＩＤＥが更にソース・コード・エディターを含む、ステップと、
前記ブラウザーにおける前記ユーザー選択を、フェッチ・ファイルにおける位置範囲にマッピングするステップであって、前記フェッチ・ファイルが、ハイパーテキスト転送プロトコル（ＨＴＴＰ）要求に応答して、ウェブ・サーバーから受信したファイルを含む、ステップと、
前記フェッチ・ファイルにおける前記位置範囲を、前記ブラウザーにおいて前記ユーザー選択を生成したソース・ファイルにおける位置範囲にマッピングするステップと、
前記ソース・ファイルに対しなされたユーザー変更を受けるステップであって、変更されたソース・ファイルが前記ユーザー変更にしたがって生成される、ステップと、
前記変更されたソース・ファイルを前記ウェブ・サーバーにアップロードするステップと、
前記変更されたソース・ファイルに基づいて前記ウェブ・サーバーからアップデートされたコンテンツを受けるステップと、
前記ブラウザーにおける前記ユーザー選択を、前記ソース・コード・エディターにおける前記変更されたソース・ファイルと同時に表示するステップであって、表示される前記変更されたソース・ファイルが、前記ブラウザーにおける前記ユーザー選択に対応する前記位置範囲までスクロールされる、ステップと、
を含み、前記ブラウザーにおける表示された前記ユーザー選択が、前記アップデートされたコンテンツを含む、方法。
請求項５記載の方法であって、更に、
前記フェッチ・ファイルにおける位置範囲を、前記フェッチ・ファイルの前記位置範囲においてコンテンツを発生したソース・ファイルにおける対応する位置範囲にマッピングするメタデーターを受信するステップを含み、前記メタデーターが、前記ソース・ファイルへのパスと、前記フェッチ・ファイルにおける前記位置範囲に対応する前記ソース・ファイルにおける前記対応する位置範囲とを含む、方法。
請求項６記載の方法であって、更に、
前記ソフトウェア開発コンピューターのメモリーにおいてマッピング・テーブルを生成するステップを含み、前記マッピング・テーブルが、前記フェッチ・ファイルとブラウザー・ファイルとの間で関連を作ることによって、前記ブラウザーにおけるコンテンツを、前記フェッチ・ファイルにおける対応するコンテンツにマッピングする、方法。
請求項７記載の方法であって、更に、サーバー・コンテンツを生成する要求を前記ウェブ・サーバーに送ることによって前記サーバー・コンテンツを生成し、前記ブラウザーにおいて前記サーバー・コンテンツを表示するステップを含む、方法。
請求項５記載の方法であって、更に、
ブラウザー・ページを表すツリー・データー構造を表示するステップを含み、前記ブラウザー・ページが前記ブラウザー内に表示される、方法。
コンピューター実行可能命令を含むコンピューター読み取り可能記憶媒体であって、前記コンピューター実行可能命令を実行すると、計算デバイスの少なくとも１つのプロセッサーに、
統合開発環境（ＩＤＥ）に含まれたブラウザーにおける選択を受けるステップであって、前記ＩＤＥが更にソース・コード・エディターを含む、ステップと、
前記ブラウザーにおける前記選択を、ダイナミック・ブラウザー・ファイルのブロック・リストにおける位置範囲にマッピングするステップと、
前記ダイナミック・ブラウザー・ファイルのブロック・リストにおける前記位置範囲を、フェッチ・ファイルのブロック・リストにおける位置範囲にマッピングするステップであって、前記フェッチ・ファイルが、ウェブ・サーバーから受信されたファイルを含む、ステップと、
前記フェッチ・ファイルのブロック・リストにおける前記位置範囲を、前記ブラウザーにおいて前記選択を生成したソース・ファイルにおける対応する位置範囲にマッピングするステップと、
前記ソース・ファイルに対しなされた１つ以上のユーザー変更を前記ウェブ・サーバーが処理して変更されたソース・ファイルを生成することに基づいて、前記ウェブ・サーバーからアップデートされたコンテンツを受けるステップと、
前記ブラウザーにおける前記選択と、前記ソース・コード・エディターにおける前記変更されたソース・ファイルとを前記ＩＤＥにおいて同時に表示するステップであって、表示される前記変更されたソース・ファイルが、前記対応する位置範囲までスクロールされる、ステップと、
を行わせ、前記ブラウザーにおける表示された前記選択が前記アップデートされたコンテンツを含む、コンピューター読み取り可能記憶媒体。