| Oracle® Fusion Middleware WebCenter Sites管理者ガイド 11gリリース1 (11.1.1.8.0) E49682-01 |
|
 前 |
 次 |
Oracle WebCenter Sites 11.1.1.8.0以降、WebCenter Sitesではすべてのアセット・タイプにバニティURLを作成できます。バニティURLは、短くてわかりやすい、管理の簡単なURLです。通常は、名前のように読んでわかりやすい情報か、バニティURLが参照するWebページのコンテンツを説明する情報で構成されます。
バニティURLは、製品の既存のURLに置き換わるものではありません。バニティURLは既存のURLと共存し、どちらを使用してもコンテンツにアクセスできます。バニティURLは、自動生成するか、コンテンツ・コントリビュータがWebCenter Sites Contributorインタフェースでカスタム作成します。
次に示すのは、通常のWebCenter Sites URLの例です。
http://www.example.com/cs/Satellite?c=Page&cid=3451344545&pagename=avisports/Page/HomeLayout
同じアセットに、次のようなバニティURLを指定できます。
http://www.example.com/Running/Home
この例からわかるように、バニティURLのほうが(特にモバイル・デバイス上で)簡単に入力でき、ユーザーが読んだり、後で思い出したりしやすいという利点があります。
バニティURLは2つの部分から構成されます。1つ目のWebRootは、様々な環境におけるバニティURLの解釈方法を制御します。2つ目はURLパターンまたは自由形式エントリです。URLパターンは、アセット・タイプ全体を対象として定義するルールです。自由形式エントリは、コンテンツ・コントリビュータが各アセットに個別に作成します。
この章は、次の項で構成されています。
WebRootは、バニティURLの解釈方法を制御するために使用します。WebRootはアセットに似ています。WebRootを配信システムで使用するには、構成した後に宛先にパブリッシュする必要があります。
WebRootには、絶対と相対の2つの形式があります。絶対WebRootには、URL接頭辞全体(ホストとポートの情報を含む)を使用する必要があります。また、オプションですべてのサーバーに固有のパス接頭辞を使用できます。相対WebRootには、パスに関する情報のみを使用し、ホストまたはポートに関する情報は使用しません。WebCenter SitesではどちらのURLも同一の方法で処理されます。ただし、相対WebRootの場合、インスタンスの開発、ステージング、本番など、複数の環境を通じて1つのWebRootのみ使用します。絶対WebRootの場合、それぞれの環境に固有のWebRootを使用します。
この制限を解消するために、VirtualRootという概念がサポートされています。VirtualRootを使用するには、特定の環境でそれが有効であることを識別するために、futuretense.iniに環境識別子を設定する必要があります。このパラメータが指定されていない場合は、WebRootが使用されます。絶対ルートと相対ルートの両方を同時に定義する状況がありうるため、WebRootのタイプを決定および理解することは重要です。表24-1に、WebRootの各タイプの利点と欠点をまとめます。
表24-1 WebRootの各タイプの利点と欠点
| WebRootタイプ | 利点 | 欠点 |
|---|---|---|
|
絶対WebRoot |
|
|
|
相対WebRoot |
|
|
|
両方を併用 |
|
|
1つのURLに必要な様々なタイプのWebRootの例
次の例では、この章の冒頭で示したバニティURL (http://www.example.com/Running/Home)を使用し、管理サーバーと本番サーバーでそのURLを使用したり、アクセスしたりする方法を示します。
各環境で使用するバニティURLは次のとおりです。
本番: http://www.example.com/Running/Home
管理: http://management.example.com/Running/Home
パス部分であるURLのRunning/Homeパスの詳細は、第24.2項「バニティURLの生成」を参照してください。
本番サーバーに使用するサーバー名はhttp://www.example.com/、管理サーバーに使用するサーバー名はhttp://management.example.com/です。
絶対WebRootの場合、ルートURLをhttp://www.example.comとして、各環境に固有のWebRootが必要です。futuretense.iniでsites.environmentプロパティをmanagementに設定します。サイトはAVISportsになります。
仮想ルートURIのWebRootに指定する値とsites.environmentプロパティに指定する値は同一である必要があることに注意することが重要です。
相対WebRootの場合、すべての環境を通じて1つのWebRootを使用します。ルートURLは/です。サイトはAVISportsになります。
新しいWebRootを作成するには:
「管理」タブで、「WebRoots」ノードを開き、「新規追加」をダブルクリックします。
WebRoot編集フォームが表示されますが、図24-1に示すように、すべてのフィールドは空白です。
「ホスト名」フィールドに名前を入力します。これはWebRootインスタンスの一意の識別子になります。描画タグでこれを使用して、アセットの固有のバニティURLを取得できます。
WebRootを保存した後でこの値を変更することはできません。
「ルートURL」フィールドにURLを入力します。「ルートURL」には、絶対または相対のどちらの値も入力できます。絶対WebRootの場合、通常は、配信環境でアセットのレンダリングに使用するURLを入力します。一方、相対WebRootの場合は、/<Optional PATH Prefix>を入力します。
コンテンツ・コントリビュータにとって、これは定義されているバニティURLを表示する際に接頭辞として使用するURLです。次に例を示します。
ホスト名のみを使用する絶対ルートURL
本番URL: http://www.example.com
完全なバニティURL: http://www.example.com/Running/Home
ホスト名と接頭辞の両方をパスに含む絶対ルートURL
本番URL: http://www.example.com/Prefix
完全なバニティURL: http://www.example.com/Prefix/Running/Home
モバイル・サイト向けのホスト名を含む絶対ルートURL
本番URL: http://www.example.mobi
完全なバニティURL: http://www.example.mobi/Running/Home
相対ルートURL
本番URL: /cs/example
完全なバニティURL: http://<Current Host Name>/cs/example/Running/Home
相対ルートURL
本番URL: /
完全なバニティURL: http://<Current Host Name>/Running/Home
1つ以上の仮想URLを入力します。仮想URLは2つの部分から構成されます。
環境: 他の環境の識別子。futuretense.iniでproperty sites.environment=<name>を設定して環境を指定する必要があります。
ルートURL: これは編集、ステージングなど、他の環境でアセットをレンダリングするために使用するURLです。
初期表示では、環境とルートURLを追加するための行が1つのみ存在します。「新規追加」ボタンをクリックすると、「環境」フィールドと「ルートURL」フィールドで構成される行が追加されます。
入力する仮想URLには、絶対ルートURLを使用する必要があります。次に例を示します。
http://management.example.com/Running/Homeという管理URLの場合、次のように入力します。
環境: management
ルートURL: management.example.com
futuretense.iniでsites.environment=managementと指定
http://staging.example.com/Running/HomeというステージングURLの場合、次のように入力します。
環境: staging
ルートURL: staging.example.com
futuretense.iniでsites.environment=stagingと指定
http://dev.example.com:8080/Running/Homeという開発URL (ポートを含む)の場合、次のように入力します。
環境: dev
ルートURL: dev.example.com:8080
futuretense.iniでsites.environment=devと指定
|
注意: 「仮想ルートURL」は、コントリビュータUIでの表示には使用されません。これが使用されるのは、「環境」の値が |
1つ以上のサイトを選択します。「サイト」フィールドを使用して、WebRootを特定のサイトで有効にできます。
次の例では、「サイト」にAVIsportsを設定しています。これは、このサイトに固有のURLを使用しているためです。
すべての情報を追加したら、「保存」アイコンをクリックします。WebRootが作成されます。
初めて作成した後のWebRootは、「管理」タブの「アセット・タイプ」ノードにアセット・タイプとして表示されます。
WebRootを表示するには:
「管理」タブで、「WebRoots」を開きます。リストされているいずれかのWebRootをダブルクリックします。
WebRootの「コンテンツ」フォームが開き、図24-2に示すように、保存されているそのWebRootの情報が表示されます。
既存のWebRootを編集するには:
「管理」タブで、「WebRoots」を開きます。リストされているいずれかのWebRootをダブルクリックします。
図24-2に示すように、WebRoot編集フォームが表示されます。
WebRootを編集するには、「編集」アイコンをクリックします。
図24-3に示すように、WebRoot編集フォームが表示されます。
「ホスト名」、「ルートURL」、「仮想ルートURL」および「サイト」の各フィールドに、保存されている情報が表示されます。
「ホスト名」フィールドは、WebRootインスタンスの一意の識別子です。描画タグでこれを使用して、アセットの固有のバニティURLを取得できます。
「ルートURL」フィールドは、通常は、配信環境でアセットのレンダリングに使用するURLです。これは、コンテンツ・コントリビュータに対して表示されるURLです。
「仮想ルートURL」は2つの部分から構成されます。
環境: 他の環境の識別子。futuretense.iniでproperty sites.environment=<name>を設定して環境を指定する必要があります。
ルートURL: これは編集、ステージングなど、他の環境でアセットをレンダリングするために使用するURLです。
仮想URLをさらに追加するには、「新規追加」ボタンをクリックして、「環境」フィールドと「ルートURL」フィールドで構成される行を追加します。
1つ以上のサイトを選択します。「サイト」フィールドを使用して、WebRootを特定のサイトで有効にできます。
すべての情報を追加したら、「保存」アイコンをクリックします。WebRootが更新されます。
WebRootを承認してパブリッシュするには:
WebRootは、他のアセットと同じ方法でパブリッシュ用に承認できます。それには、WebRootをプレビューした状態で、緑のチェック・マーク・アイコンをクリックします。
WebRootはブロッキング・アセットとして設定されることはありません。管理者は、WebRootを個別に承認してパブリッシュする必要があります。
バニティURLを構成する方法は2つあります。その1つは、コンテンツ・コントリビュータでバニティURLを個別に手動で構成する方法です(詳細は『Oracle Fusion Middleware WebCenter Sitesユーザーズ・ガイド』を参照してください)。この項では、パターンからバニティURLを自動的に生成するもう1つの方法について説明します。
この項は、次のトピックで構成されています。
パターンに基づくバニティURLは、個々のアセットから自動生成されます。パターンを登録した後、アセットを初めて保存する際にバニティURLが生成されます。パターンは、アセット・タイプごとに作成できますが、1つのサイトでのみ有効です。複数のサイトでアセット・タイプを共有する場合は、同じパターンを複数回作成する必要があります。
|
注意: パターンを変更した場合、それが反映されるのはアセットを作成または保存するときのみです。パターンを変更した場合、または新しいパターンを作成した場合、それらはパターンを保存した後に作成されたアセットにのみ適用されます。 |
自動生成されるバニティURLを構成するには:
「管理」タブで、「アセット・タイプ」ノードを開き、自動生成URLを作成する特定のアセット・タイプのノードを開きます。この特定のアセット・タイプのノードで「URLパターン」を開き、「新規追加」をダブルクリックします。
「URLパターン・フォーム」が表示されます。
「名前」フィールドにパターンの名前を入力します。この名前は一意で、このパターンを参照するためにのみ使用され、いつでも変更できます。
「パターン」フィールドに、バニティURLを定義するルールを入力します。使用可能な有効な属性と関数のリストが画面の右側に表示されます。パターン作成の詳細は、第24.2.2項「URLパターンの使用」を参照してください。
「BLOBヘッダー」フィールド(Blobが選択されている場合のみ入力可能)に、バニティURLのBLOBヘッダーの定義に使用するルールを入力します。
「サイト」は、パターンが適用されるサイトです。リストには、このアセット・タイプが有効なサイトのみが表示されます。サイトを選択すると、「ホスト」(WebRoot)、「サブタイプ」、「テンプレート」(アセットのみ)および「ラッパー」(アセットのみ)の選択肢も絞り込まれます。
|
注意: このサイトでこのアセット・タイプが後から無効にされても、定義されているパターンは残ります。ただし、そのようなURLを使用すると、機能しないページが表示される可能性があります。 |
「ホスト」は、バニティURLが適用されるWebRootです。このサイトに定義されているWebRootまたは「任意」のみが表示されます。WebRootが存在しない場合、パターンは機能しません。
「サブタイプ」は、バニティURLが適用されるアセット・タイプのサブタイプです。「サブタイプ」を選択すると、「テンプレート」と「ラッパー」で選択できるアイテムが絞り込まれます。
|
注意: BLOBの「サブタイプ」フィールドには、フレックス・アセットのオプションとして |
「フィールド」は、このURLでレンダリングされるBLOBです。このフィールドは、BLOBが選択された場合のみ表示されます。アセットに複数のBLOBエントリが含まれる場合、複数のアイテムが表示される可能性があります。
「ダウンロード可能」チェック・ボックスを選択すると、このバニティURLにアクセスしたとき、ブラウザでは、ページ内にBLOBオブジェクトではなく保存ダイアログが表示されます。
「デバイス・グループ」には、現在定義されている使用可能なデバイス・グループのリストが表示されます。このフィールドは、アセットが選択された場合のみ表示されます。すべてのデバイス・グループが、サイトにおける現在の状態に関係なく、拡張子に基づいてフォーマットされてリストに表示されます。デバイス・グループの詳細は、『Oracle Fusion Middleware WebCenter Sites開発者ガイド』を参照してください。
「テンプレート」はこのURLのテンプレートであり、アセット・タイプ、サブタイプおよびサイトで有効なすべてのテンプレートが、モバイル・バリエーションの有無に関係なく表示されます。有効なすべてのテンプレートが表示されますが、すべてのテンプレートに「デバイス・グループ」で指定したデバイス・グループのバリエーションが存在するわけではありません。管理者は、デフォルトではなくデバイス・グループを使用する場合に適切なバリエーションが存在することを保証する必要があります。
「ラッパー」には、「テンプレート」で選択したテンプレートで有効なすべてのラッパー要素のリストが表示されます。1つも存在しない場合、このフィールドは無効になります。
ここで、「保存」をクリックしてパターンを保存して作業を続行するか、URLパターンを評価できます。
このフォームの「URLパターンの評価」セクションを使用して、パターンに基づいて生成されるバニティURLの例を表示できます。このセクションは、パターンを保存する前または後のどちらでも使用できます。ただし、保存する前にURLパターンを評価して、パターンを検証することをお薦めします。
|
注意: 該当するタイプのアセットが存在しない場合、この機能を使用することはできません。 |
「アセット」ドロップダウン・リストでは、パターン・タイプに現在定義されているアセットを選択できます。アセットの名前を入力する際、先読み機能を使用することもできます。アセットを選択すると、WebCenter Sitesは作成されたパターンを評価し、このアセットのURLがどのように表示されるかを示します。
これは、URLの最終的な表示を示す例であることに留意してください。パターンが保存され、該当するアセットの編集および保存が行われるまで、URLは有効ではありません。
自動パターンは、バニティURLの中心的存在です。バニティURLには、コントリビュータがアセットごとにカスタムURLを作成するために使用できる別のコンポーネント(詳細は『Oracle Fusion Middleware WebCenter Sitesユーザーズ・ガイド』を参照)もありますが、管理者としては、サイトに存在するバニティURLの大部分をパターン一致によるURLで構成することが予想されます。パターンはパスと変数を組み合せた形式であり、変数はアセットから取得するフィールドまたは事前定義済関数です。
|
注意: URLのすべての部分は、保存する前にURLとしてエンコードされます。 |
存在する実際の変数は、選択されているアセット・タイプに応じて異なりますが、すべてのアセット・タイプで共有される共通変数が存在します。表24-2に、頻繁に使用される変数をリストします。
表24-2 共通のアセット・タイプ変数
| 変数名 | 変数タイプ |
|---|---|
|
createdby |
string |
|
createddate |
date |
|
description |
string |
|
enddate |
date |
|
fwtags |
array |
|
id |
long |
|
locale |
string |
|
name |
string |
|
startdate |
date |
|
status |
string |
|
subtype |
string |
|
template |
string |
|
updatedby |
string |
|
updateddate |
date |
変数をクリックすると、パターン・フィールドの末尾に表示されます。カーソルの位置に関係なく、新しいパターンが常に最後のアイテムになります。
変数は、${<Name>}のように指定します。たとえば、アセットのIDを取得するには、${id}と指定します。
タイプがstring、intおよびlongの変数は、変更せずにそのまま使用できます。
タイプがarrayの変数は、1つの値のみが抽出されるように指定する必要があります。たとえば、アセットに最初に定義されているタグを取得するには、${fwtags[0]}と指定するか、またはlistAsPath関数を使用します。配列の番号付けは0で始まり、配列の境界外の値を使用するとNULLになります。
タイプがdateの変数はフォーマットする必要があります。そのための関数としてformatDateが用意されています。
urlなどの他のタイプは、使用できないか、URL生成に使用できるように形式を変換する関数を使用する必要があります。これらの変数を使用する場合、「URLパターンの評価」オプションを使用すると便利です。
通常のJava関数も変数に追加できるように、変数はJava標準タイプを使用して定義されています。たとえば、nameというstring変数に対して、name.toLowerCase()は名前を小文字に変換します。
この項は、次のトピックで構成されています。
関数は、データを変換およびフォーマットして、バニティURLに使用する際に役に立ちます。WebCenter Sitesには、バニティURLの作成に役立つ事前定義済関数が用意されています。
関数をクリックすると、パターン・フィールドの末尾に表示されます。カーソルの位置に関係なく、新しいパターンが常に最後のアイテムになります。
事前定義済関数
spaceToUnderscore(java.lang.String)
空白を_に変換します。たとえば、Page 001がPage_001になります。
formatDate(java.util.Date, java.lang.String)
日付を数字とスラッシュを使用した形式にフォーマットします。たとえば、updatedateが"Thu Feb 28 12:57:12 UTC 2013"である場合、formatDate関数を使用して"2/28/2013"と表示できます。日付のフォーマットに使用する文字列は、JavaのSimpleDateFormat関数で使用する文字列と一致する必要があります。
spaceToDash(java.lang.String)
空白を-に変換します。たとえば、Page 001がPage-001になります。
listAsPath(java.util.List, int)
配列を、その先頭のx個のアイテムのリストに変換します。たとえば、[1, 2, 3 ,4, 5, 6]という配列に対してlistAsPathをx = 4で使用すると、1\2\3\4というリストが生成されます。
x (intで定義)は必須です。
getFileName(com.fatwire.assetapi.data.BlobObject)
BLOBオブジェクトのファイル名をテキストとして取得します。たとえば、BLOBの名前がxyz.pngである場合、テキストxyz.pngを返します。通常は、これを一番最後に使用して、正しいファイル拡張子を指定します。
この関数は、アセット・メーカー・アセットのバイナリ・フィールドには使用できません。
property(java.lang.String, java.lang.String, java.lang.String)
iniファイルまたはプロパティ・ファイルからプロパティを読み取ります。これはics.GetPropertyを使用します。このメソッドのパラメータは、1)プロパティ名、2)プロパティが存在しない場合のデフォルト値、3)ファイル名のカンマ区切りリストです。
関数は、${f:<name>(<variables>)}という形式で指定します。したがって、前述のspaceToUnderscoreの例の関数は次のように記述します。
${f:spaceToUnderscore("Page 001")}
記述が正しくない場合、または無効なパラメータを渡した場合、「URLパターンの評価」セクションで、パスの該当する部分にはNULLが返されます。最も外側の変数のみ${}を使用する必要がありますが、すべての関数は先頭にf:を指定する必要があります。
ここでは、AVISports記事アセット・タイプに基づいて例を示します。アセット名は、"Baker Likely to Stay With Stars"です。
|
注意: URLの先頭部分は常にWebRootです。AVISportsの場合、これはローカル・システム名とコンテキスト・ルートです。次の部分のAviは、フィルタ接頭辞です(フィルタの詳細は、Mod_rewriteに関する項を参照)。この後の例では、実際の固有のパスのみを示します。 |
アセット"Baker Likely to Stay With Stars"に対して、URL生成に使用できる様々なオプションがあります。それぞれの例で、関数と生成されるURLを示します。
まずは単純な名前のパターンです。
/Article/${name}
/Article/Baker+Likely+to+Stay+With+Stars
名前を小文字に変換します。
/Article/${name.toLowerCase()}
/Article/baker+likely+to+stay+with+stars
このURLから空白を削除します。
/Article/${f:spaceToUnderscore(name)}
/Article/Baker_Likely_to_Stay_With_Stars
複数の変数を使用します。
/Article/${id}/${createdby}
/Article/1328196049037/fwadmin
関数内部で関数を使用します。
/Article/${(f:formatDate(createddate,"yy/MM/dd")}
/Article/12-04-27
パターンは、アセット・タイプとともに自動的にパブリッシュされます。URLパターンの場合、特に承認またはパブリッシュする必要はありません。
管理者は、「システム・ツール」ノードを使用して、現在定義されているすべてのバニティURLを表示できます。
この項は、次のトピックで構成されています。
作成されているバニティURLを表示するには:
「管理」タブで、「システム・ツール」ノードを開きます。
「URL」をダブルクリックします。
「URLユーティリティ」フォームが表示されます。
このリストには、(すべてのサイトで)定義されているすべてのURLが表示されるので、用意されている検索ボックスを使用してフィルタすることによって、目的のURLを探す必要があります。このメニューから、バニティURLの手動による削除、問題の有無のチェック、競合の発生元の確認を実行できます。ただし、パターンに基づいて生成されたURLは、アセットが次回保存されたときに自動的に再生成されます。
同じパスを持つバニティURLは(WebCenter Sites全体でも) 1つしか存在できないので、バニティURLは一意です。
たとえば、2つのサイトがあり、各サイトにルール・パターン/Page/${name}が存在し、両方でページに同じ名前(たとえば"Home")を使用している場合、競合が発生します。
これは、どちらのページであっても、先に保存したページは正常に保存されてバニティURLが作成されますが、後から保存したページはバニティURLの作成に失敗することを意味します。この場合、システム・ツールを使用してバニティURLの作成を阻害する原因を特定し、必要に応じて既存のURLを削除して、新しいURLを作成できるようにする必要がある可能性があります。この問題は、WebRootが特定のサイトに固有であることを保証することによって抑止できます。
バニティURLを解決する方法は2つあります。1つは、Webサーバーを使用してURLをリライトする方法です。もう1つは、開発時によく見られる、Webサーバーが存在しない場合のために設計された方法で、フィルタを使用します。
WebCenter Sitesにはデフォルトで、サンプル・サイト専用のURLリライタ・フィルタが用意されています。このリライタ・フィルタは、任意のサイトでWebRootと組み合せて使用するように構成できます。このフィルタは、(先頭からの文字列一致に基づいて)フィルタを通過するすべてのコールをインターセプトし、バニティURLフィルタとしてWebCenter Sitesに渡します。
簡単に言えば、Webサーバー上にリライト・ルールが存在しなくてもバニティURLが動作するようにできます。このフィルタを使用する場合の重要な制限として、WebCenter SitesがバニティURLとして処理するURLを認識できるように、コンテキスト・ルート、さらに一意な接頭辞を指定する必要があります。
|
注意: "FSII"と"Avi"は、サンプル・サイトがインストールされる際に、 |
リライタ・フィルタを有効にするには:
次のコードを、web.xmlの一番最後に記述されている</filter>の後にコピーします。次に、Aviを一意の文字列(たとえばサイト名)で置き換えて、WebCenter Sitesを再起動します。
|
注意:
|
<filter>
<filter-name>URLRewriteFilter</filter-name>
<filter-class>COM.FutureTense.Servlet.URLRewriteFilter</filter-class>
<init-param>
<param-name>SitePrefix</param-name>
<param-value>Avi</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>URLRewriteFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
接頭辞に一致するWebCenter Sitesの内部にWebRootを作成します。たとえば、"Avi"を使用する場合、/<contextroot>/Aviで始まるWebRootを作成する必要があります。相対WebRootを使用する場合は、他に指定する必要はありません。絶対WebRootを使用する場合は、ホスト名とポートも指定する必要があります。保存する前に、このWebRootが定義されているサイトを選択する必要があります。
保存した後、新しいWebRootを使用するURLを1つ作成します。
作成したバニティURLがブラウザで機能することを確認します。
次に例を示します。
相対WebRootが/Avi、パスが/Running/Homeである場合、フィルタによって次のようなURLが生成されます。
http://<Sites Host>:<Sites Port>/<Context Root>/Avi/Running/Home
フィルタを使用するので、フィルタとWebRootの両方で接頭辞(具体的に言うと、この例ではAvi)を使用する必要があります。
|
注意: バニティURLは、問合せパラメータをサポートします。必要なパラメータがバニティURLから削除されていても、場合によってはURLの一部として追加データを渡す必要があることはわかっています。そのような場合、既存のパラメータを既存のURLに連結する必要があります。たとえば、 http://<Sites Host>:<Sites Port>/<Context root>/Avi/Running/Home?time=true |
多くの場合、モバイル固有のサイトを使用するユーザーは、モバイル・ユーザー専用のURLを使用することを望みます。短いURLがモバイル・ユーザーに利点をもたらすだけでなく、通常は固有のドメインとURLが存在するためです。Webサイトのモバイル・ページ用に固有のドメインとURLを設定するには、次の手順を実行する必要があります。
モバイル・ドメイン名用のWebRootを設定する必要があります。WebRootのルートURLには、モバイル・ドメイン名を使用する必要があります。
モバイル・デバイス・グループ用のバニティURLを作成する際、正しいホスト名を選択する必要があります。これにより、モバイル・ドメイン名用のリンクが正しく生成されることが保証されます。
WebサーバーのURLのリライトなど、他のすべての手順は、第24.1項「WebRoot」、第24.2項「バニティURLの生成」および第24.3項「システム・ツールによるバニティURLの使用」に示す手順と同じです。
URLのリライトにWebサーバーを使用することで、フィルタと同じ方法でバニティURLにアクセスでき、URLリライトに伴うすべての制御と機能を利用できます。
Webサーバーを使用する場合、リライトされるバニティURLはすべて、WebCenter Sitesに送信される前に2つに分割する必要があります。1つはWebRoot、もう1つはパスです。
例を示します。WebRootのhttp://www.example.com、および/Running/Homeを生成するパターンを使用して、http://www.example.com/Running/HomeというURLを生成します。WebサーバーからこのURLを渡すために、URLをWebRootとパスに分割する必要があります。これらはそれぞれ問合せパラメータとしてWebCenter Sitesの特殊フィルタに渡されます。リライトされたURLの処理に使用されるバニティURLフィルタには"Sites"という名前が付けられており、<content root>/Sitesでアクセスします。
URLの2つの部分は分割されて、それぞれlookuphostとlookuppageに格納されます。lookuphostはWebRootを参照します(絶対WebRootの場合はフル・サーバー名、ポートおよび接頭辞、相対WebRootの場合は接頭辞のみ)。lookuppageは接頭辞の後のパスの残りの部分を参照します。例に示したURLを使用する場合、WebCenter Sitesに渡すURLは、次のようにリライトされている必要があります。
http://<Sites Host>:<Sites Port>/<contextpath/Sites?lookuppage=/Running/Home &lookuphost=http://www.example.com
|
注意: バニティURLは、問合せパラメータをサポートします。必要なパラメータがバニティURLから削除されていても、場合によってはURLの一部として追加データを渡す必要があることはわかっています。そのような場合、既存のパラメータを既存のURLに連結する必要があります。 たとえば、 http://<Sites Host>:<Sites Port>/<contextpath/Sites?lookuppage=/Running/Home &lookuphost=http://www.example.com&time=true |
Webサーバーとサイトの組合せはすべて一意なので、次の内容は、mod_rewrite (OHS、ApacheおよびIBM HTTPサーバーでURLのリライトに使用される)の使用方法のガイドラインおよび例として参照する必要があります。ほとんどのシステムでは、示されているルールを正しく動作させるために変更が必要です。
mod_rewriteを使用する方法は2つあります。1つはSitesフィルタに渡すためにURLを直接変換する方法、もう1つはURLリライタ・フィルタと一緒に使用して同じアクションを実行しますが、ずっと単純なmod_rewriteのルール(既存のサイトでそれまでコンテキスト・ルートの削除に使用していたルールとほぼ同様)を使用できる方法です。ここでは、両方の方法の例を示します。適切な方法を決定するには、まず、SitesフィルタでバニティURLを分割する余分な手順(すなわちコスト)が、単純化されたリライト・ルールに値するかどうかを判断します。
|
注意: ここでは、
|
これ以降の手順はすべて、手動コンパイルされているApache 2.4.xをベースにしています。OS付属のバージョンを使用する場合、mod_rewriteを有効にして構成するために必要な実際の変更手順は異なる可能性がありますが、ルールと概念は同じです。
この項は、次のトピックで構成されています。
最初に、httpd.confを編集し、次の行を非コメント化することによってmod_rewriteを有効にします。
LoadModule rewrite_module modules/mod_rewrite.so
次に、httpd.confに次の行を追加して、リライト・エンジンを有効にします。
RewriteEngine On
次に、デバッグ用に、mod_rewriteのロギングのみ有効にします(これは非常にコストの高い操作なので、デバッグ時のみ使用してください)。
LogLevel alert rewrite:trace6
httpd.confへの変更を保存します。これで、mod_rewriteが有効になります(ルールはなし)。最後に、Webサーバーの起動を確認します。
|
注意: 比較的簡単に構築してテストできるWebページがあります。初めて |
用意されている例の設定
mod_rewriteルールの例を提供するために、最初に環境について定義する必要があります。次に示すのは、このガイドで使用しているバニティURLに基づくサンプルです。ただし、これらの要素を出発点として環境に合わせて値を変更するだけで、使用できるようになるはずです。
ユーザーが使用することになるバニティURL:
本番:
http://www.example.com/Page/Surfing http://www.example.com/Article/Baker_Likely_to_Stay_With_Stars http://www.example.com/Home http://www.example.com/Home?time=true
開発:
http://dev.example.com:8080/Running/Home
Sitesの一般情報:
本番コンテキスト・ルート: /cs
本番リライト・フィルタ: /AVISPORTS
開発コンテキスト・ルート: /csdev
開発リライト・フィルタ: /Avi
各サーバーに定義されているWebRoot:
本番 - 絶対: http://www.example.com
開発 - 相対: /Avi
URL構造:
本番: http://www.example.com/Page/Surfing
WebRoot: http://www.example.com
パス: /Page/Surfing
本番: http://www.example.com/Article/Baker_Likely_to_Stay_With_Stars
WebRoot: http://www.example.com
パス: /Article/Baker_Likely_to_Stay_With_Stars
本番: http://www.example.com/Home
WebRoot: http://www.example.com
パス: /Home
本番: http://www.example.com/Home?time=true
WebRoot: http://www.example.com
パス: /Home
問合せパラメータ: time=true
開発: http://dev.example.com:8080/Running/Home
WebRoot: /Avi
パス: /Running/Home
フィルタは2つあります。1つはSitesバニティURLフィルタ、もう1つはSitesリライト・フィルタです。リライト・フィルタを使用する場合、データはリライト・フィルタからバニティURLフィルタに透過的に渡されます。
SitesバニティURLフィルタを使用する場合、URLは次のようになります。
本番:
http://www.example.com/Page/Surfing
lookuphost=http://www.example.com &lookuppage=/Page/Surfing
http://www.example.com/Article/Baker_Likely_to_Stay_With_Stars
lookuphost=http://www.example.com &lookuppage=/Article/Baker_Likely_to_Stay_With_Stars
http://www.example.com/Home
lookuphost=http://www.example.com &lookuppage=/Home
http://www.example.com/Home?time=true
lookuphost=http://www.example.com &lookuppage=/Home&time=true
開発:
http://dev.example.com:8080/Running/Home
lookuphost=/cs/Avi&lookuppage=/Running/Home
WebCenter Sitesリライタ・フィルタを使用する場合、URLは次のようになります。
本番:
http://www.example.com/Page/Surfing
/cs/AVISPORTS/Page/Surfing
http://www.example.com/Article/Baker_Likely_to_Stay_With_Stars
/cs/AVISPORTS/Article/Baker_Likely_to_Stay_With_Stars
http://www.example.com/Home
/cs/AVISPORTS/Home
http://www.example.com/Home?time=true
/cs/AVISPORTS/Home?time=true
開発:
http://dev.example.com:8080/Running/Home
/csdev/Avi/Running/Home
URLを選択してコンポーネント部分に分割した後は、mod_rewriteを使用してこれらのURLを変換する必要があります。mod_rewriteのルールは2つの部分で構成されます。前半部分はWebサーバーに渡されるURLと比較する正規表現であり、後半部分は変換後に渡されるデータです。前半部分が一致しない場合、URLは次のリライト・ルールに渡されます。定義されているどのルールも一致しない場合、URLは変更されないままで渡されます。したがって、複数のルールが存在する場合、その順序が重要になります。
|
注意: 1. ここで説明する内容は、 |
mod_rewriteルールのコンポーネント部分
この例では、本番用の最初のURLであるhttp://www.example.com/Page/Surfingを使用します。
このURLに次のルールを作成します。
RewriteRule ^(.*)$ /cs/Sites?lookuphost=http://www.example.com&lookuppage=$1 [L]
このルールには、次に示す4つのコンポーネント部分があります。
RewriteRule — 後に続くエントリがmod_rewriteルールであることを示す文。
^(.*)$ — 正規表現。次のように分割されます。
^ — 行インジケータの開始
(.*) — 全テキスト一致選択インジケータ。カッコ内に記述すると、選択されたテキストが変数に保存されます。
$ — 行インジケータの終了
したがって、この式は、文字列の開始と終了の間にあるすべてのテキストを変数に保存することを示します。
/cs/Sites?lookuphost=http://www.example.com&lookuppage=$1 — バニティURLのWebCenter Sitesコンテキスト・ルート、フィルタおよびパス。次のように分解されます。
/cs/Sites — Sitesコンテキスト・ルート(cs)およびバニティURLフィルタ(Sites)
? — この後に続くパラメータが問合せパラメータであることを示す
lookuphost=http://www.example.com
lookuphost — バニティURLフィルタにWebRootの名前を提供
http://www.example.com — 本番サーバーのWebRoot (絶対WebRoot)
lookuppage=$1
lookuppage — バニティURLのパス部分(この場合は/Page/Surfing)
$1 — 入力URLから抽出した1番目のテキストを示す置換変数。この場合は(.*)と一致した/Page/Surfing
[L] — mod_rewriteにルールの終了を通知します。すべてのmod_rewriteルールは、最後にこれを記述する必要があります。
次のルールは/Page/Surfingだけでなく、送信された他のすべてのページも処理して、ホストの後から行の終了までのすべてを抽出します。
RewriteRule ^(.*)$ /cs/Sites?lookuphost=http://www.example.com& lookuppage=$1 [L]
したがって、次のURLはこのルールで処理されます。
http://www.example.com/Article/Baker_Likely_to_Stay_With_Stars http://www.example.com/Home
しかし、次のURLはこのルールで処理されません。
http://www.example.com/Home?time=true
なぜなら、このURLには、ホストとパス以外に、問合せパラメータが渡されているためです。問合せパラメータを処理するには、変数"%{QUERY_STRING}"を組み込んだmod_rewriteを使用する必要があるので、前述のルール
/cs/Sites? lookuphost=http://www.example.com& lookuppage=$1
を、次のように更新する必要があります。
/cs/Sites? lookuphost=http://www.example.com& lookuppage=$1&%{QUERY_STRING}
問合せパラメータを渡さないURLの場合、%{QUERY_STRING}は空になります。したがって、前述の3つのURLに加えて、次のURLも処理できます。
今度は次の開発URLについて考えます。
http://dev.example.com:8080/Running/Home .
これを、次のようにしてバニティURLフィルタに渡す必要があります。
lookuphost=/cs/Avi&/cs/Sites?lookuppage=/Running/Home .
mod_rewriteは、デフォルトではホストとポートを処理しないので(この情報を含む専用パラメータが存在します)、リライト・ルールは次のルールによく似たものになります。
RewriteRule ^(.*)$ /cs/Sites?lookuppage=$1&lookuphost=/cs/Avi [L]
この場合、開発では相対WebRootを利用するので、名前を調整する必要があります。URLの残りの部分は変更されないため同じルールが適用されます。
リライト・フィルタを使用する場合、バニティURLフィルタの場合のようにURLを分割する必要はありません。かわりに、Sitesコンテキスト・ルートおよびリライタ・フィルタ接頭辞がURLに追加されます(これはバニティURLの導入前のWebCenter Sitesを使用する場合とよく似ています。したがって、既存のルールは、バニティURLをサポートするように簡単に変更できます)。
例のURLを使用します。
http://www.example.com/Page/Surfing
Sitesには次を渡します。
/cs/AVISPORTS/Page/Surfing
これを処理するために、次のmod_rewriteルールを新しく作成します。
RewriteRule ^(.*)$ /cs/AVISPORTS$1 [L]
このルールは、単純に渡されたものを受け取り、その先頭に/cs/AVISPORTSを追加します。同じルールで次も処理できます。
http://www.example.com/Article/Baker_Likely_to_Stay_With_Stars http://www.example.com/Home
次のURLについて考えます。
http://www.example.com/Home?time=true
これを処理するには、ルールに%{QUERY_STRING}パラメータを追加します。したがって、次のようになります。
RewriteRule ^(.*)$ /cs/AVISPORTS$1?%{QUERY_STRING} [L]
mod_rewriteとバニティURLを使用する場合の最大の問題の1つが、既存のCSSと静的イメージのアクセスです。通常、これらはアプリケーション・サーバー上またはWebサーバー上にある、サイトと同じ名前のディレクトリに格納されます。これは、通常はリライト・ルールによって、それらにアクセスできなくなることを意味します。
例のURLを使用します。
http://www.example.com/Page/Surfing
さらに、CSSファイルは、AVISPORTS_STATICという名前のディレクトリに格納されているものとします。
これを処理するために、2つ目のmod_rewriteルールを作成します。このルールを前述のルールの前に置くことによって、このディレクトリへのコールがリライトされないことを保証します。
これは、次のようにして実現できます。
RewriteRule ^.*/AVISPORTS_STATIC/(.*)$ /cs/CSPerformance/$1 [L,PT].
これらの2つのルールを使用して、1つ目のルールですべての静的ページとCSSがバニティURLに変換されないことを保証し、2つ目のルール(第24.7.2項「mod_rewriteによる変換」で構築)で残りのURLをバニティURLフィルタに送信します。
RewriteRule ^.*/AVISPORTS_STATIC/(.*)$ /cs/CSPerformance/$1 [L,PT] RewriteRule ^(.*)$ /cs/Sites?lookuphost=http://www.example.com&lookuppage=$1 [L]
