【新機能】Vanity URLを試してみる(その2)

前回:【新機能】Vanity URLを試してみる(その1

 前回 からだいぶ空いてしまいましたが、Vanity URLその2ということで書かせていただきました。代わりに書いてくれる人を探しましたが誰もいなかったので、このブログは担当が独自に調査して書いています。多少間違っていても温かい目で見守って頂けますと幸いです。

前回の「その1」では、アセットごと(ページ単位とも言えます)でのVanity URLの設定について試してみました。今回はアセットタイプ毎のVanity URLの設定を試してみようと思います。

同じアセットタイプのアセットを用いて表示するページのURLをあるパターンに従って自動生成してみます。

前回同様、JSKのサンプルサイトFirstSiteIIを用いて検証していきます。

※その1の公開(2013年12月)から3ヶ月ほど経ちましたが、その間にドキュメントも日本語版が公開されています。

http://docs.oracle.com/cd/E51625_01/doc.1111/e49682/config_vanity_url.htm#i1093062

1. 自動生成されるVanity URLを設定する箇所

Vanity URLの自動生成はアセットタイプ毎(または定義毎)に設定します。よって、同じアセットタイプのアセットをプライマリとして表示するページが複数存在する、一覧表示を行うようなページで設定するのが良いと思われます。

今回はサンプルサイトFirstSiteIIのHot Productsのページから各製品の詳細ページへ遷移するURLにVanity URLを設定してみます。

http://localhost:9080/cs/Satellite?c=Page&childpagename=FirstSiteII%2FFSIILayout&cid=1124747609912&pagename=FSIIWrapper

vanity_02_01

一覧の一番上の「FSE Digital Audio Player」のリンクURLは次の通りとなっています。

http://localhost:9080/cs/Satellite/FirstSiteII/FSII/Product_C/1114083739350/1124747609912?packedargs=locale%3D1154551493541

このリンクはプライマリアセットがProduct_Cとなり、その下の「FSII Innovative HiFi VHS」のリンクURLも同様のパターンとなっています。よって、Product_CのアセットタイプにVanity URLを設定してやることで、この一覧の製品詳細ページのリンクURLにVanity URLの自動生成が適用できます。

現状、このURLにはURLアセンブラが設定されていますので、クエリのみで組み合わせたわかりづらいURLではありませんが、今回はこのURLにVanity URLを設定し、両方設定した場合はどうなるか、ということも確認してみます。

ちなみに上記のURLでアセンブラが設定されていない場合のURLは以下の通りとなります。

http://localhost:9080/cs/Satellite?c=Product_C&childpagename=FirstSiteII%2FFSIILayout&cid=1114083739350&p=1124747609912&packedargs=locale%3D1154551493541&pagename=FSIIWrapper

2. 自動生成URLの構成

Vanity URLの自動生成を構成します。上記のURLをみて分かる通り、プライマリアセットのタイプは「Product_C」であるためそのアセットタイプに対して設定を行います。

管理画面のAdmin UIから「管理」タブを選択し「アセット・タイプ」→「Product_C」→「URLパターン」を選択します。

そこで「新規追加」をクリックします。

vanity_02_02

Asset/Blob Product_Cのアセットであるため、Assetを選択します。(Blobは画像やバイナリファイルの場合に用います。)
サイト FirstSiteIIのままとします。
ホスト その1で用いたものと同じWebrootの「http://localhost:9080/cs/fsii」を選択します。
サブタイプ アセットのサブタイプ(定義)を絞り込む場合に用います。今回は任意とします。
デバイスグループ 今回はそのままとします。
Template そのままとします。
ラッパー FSIIWrapperとします。
パターン 今回はシンプルに次の通りとします。
Product_C/${name}.html
${name}のところはアセット名が入ります。おそらくアセットを特定するための変数を組み込む必要がありますが、右側の表で表示される変数名が使えます。また簡単な関数も使うことができます。

最後に保存を行います。

次に実際の表示アセットProduct_Cを参照します。

Contributor UI にて、「FSE Digital Audio Player」のアセット(1114083739350 )を参照します。

vanity_02_03

既存のアセットタイプに対してVanity URLの自動生成を設定したため、実際にVanity URLの設定を反映させるために、アセットの再保存を行います。

鉛筆マークから編集ページを表示し、そのまま保存します。

その後、URLタブを表示します。

vanity_02_04

Vanity URLが自動生成されています。

今回はすでに作成済みのアセットについて後から自動構成を設定したため、アセットの再保存を行いましたが、アセットタイプに対してVanity URLの設定を行ってから新規作成する場合は再保存の必要はありません。

同様の処理を「Innovative HiFi VHS 」アセットID: 1114083739696のアセットについても行います。

設定が終わったら、再度Hot Productsのページを開いてみます。

vanity_02_05

FSII FSE Digital Audio Player のリンクURLは

http://localhost:9080/cs/fsii/Product_C/FSII+FSE+Digital+Audio+Player.html?p=1124747609912&packedargs=locale%253D1154551493541

となりました。無事にVanity URLが設定されました。

クエリの部分を除くと、自動生成のパターンとして設定した

Product_C/${name}.html

の通りとなっています。

また、その下のFSII Innovative HiFi VHSのリンクURLもVanity URLで設定したパターンになっています。

URL中のpと、packagedargsのクエリパラメータはURLパターンに組み込まれないため、そのままクエリ文字列として出力されます。クエリパラメータがなくなってしまうといった心配もありません。

3. Vanity URLとURLアセンブラ

Vanity URLをひと通り試してみましたので、Vanity URLとURLアセンブラを私なりに比較してみました。

  • 通常URL
http://localhost:9080/cs/Satellite?c=Product_C&childpagename=FirstSiteII%2FFSIILayout&cid=1114083739350&p=1124747609912&packedargs=locale%3D1154551493541&pagename=FSIIWrapper
  • URLアセンブラ(fsiiの場合)
http://localhost:9080/cs/Satellite/FirstSiteII/FSII/Product_C/1114083739350/1124747609912?packedargs=locale%3D1154551493541
  • Vanity URL
http://localhost:9080/cs/fsii/Product_C/FSII+FSE+Digital+Audio+Player.html?p=1124747609912&packedargs=locale%253D1154551493541

上記からも分かる通り、URLアセンブラの場合は、アセットタイプ、アセットIDと、また、p=で渡しているID(これはPageアセットのIDですが)もURLの一部として組み込まれています。p のパラメータ名はURL中に出てきませんので、こちらは変換ロジックで決定されているものと思われます。

Vanity URLの方はProduct_CのアセットIDがURL中に含まれず、代わりにアセット名が出力されています。PのIDはクエリとして付加されています。/Product_C/ の部分も別の名称に変えることもできると思います。

このパターンは管理画面から自由に設定できますがおそらくアセットを識別するための変数はひとつ以上は含める必要があるのではないかと思います。

Vanity URLの場合のメリットとデメリットについて考えてみました。

Vanity URLはアセット(個別、もしくはアセットタイプごと)に設定を行うため、一つのアセットタイプに関する情報しかURLに組み込むことができないと思います。それ以外に渡されるパラメータをURL中に含めることはおそらくできません。これはデメリットですが、逆にシンプルでわかりやすいと思います。

URLの設定は管理画面上から行うことができ、運用担当者でも任意にURLを設定できるというのが大きなメリットかと思います。変換後のURLを管理画面で確認することもでき、また管理タブのシステムツールから現在設定されているURLの一覧を確認することができます。

URLアセンブラに関しては、ここでは詳しくは触れませんが、変換ロジックを独自に実装する必要があり、管理画面上でVanity URLのように編集が必要であれば、管理画面側のカスタマイズも必要となるかもしれません。また変換パターンに関しても、どこかに保持しておく必要があるため、その方法についても考える必要があります。

その代わり、独自に実装できるため、URLの自由度は高くなります。複数のアセットIDを組み合わせたり、任意の文字列を組み込んだりといったことが実装次第で可能となります。その分、複雑になるため運用者が管理するのは難しくなる可能性はあります。開発者側で管理する必要が出てくるかもしれません。

最後に、簡単にまとめますと、

Vanity URLは扱いが簡単であるが、設定できるURLにはある程度制限がある。標準で準備されているため運用者側でも扱いやすい。(ある意味URLアセンブラの実装の一つとも言えるかもしれません)

URLアセンブラはURLの自由度は高い(実装次第)が、標準機能として用意されていないため作りこみが必要。運用を考慮して作りこむ必要があり、場合によっては開発サイドでメンテナンスが必要となる。

どちらにもメリット、デメリットはあると思いますので、場所によって使い分ける、といった使い方がよいかもしれません。

※上記の記述は担当が調査した範囲での記述となります。その正確性、完全性についてはジークス社は責任を負いません。