Deletions are marked like this. | Additions are marked like this. |
Line 113: | Line 113: |
== パンくずリスト実装の方針 == * すべてのブックマーク可能ページは単一の木構造の中のいずれかの位置に固定的に存在する。 * ただし、ブックマーク不可能なページはどこに現れてもよい。それらは、ブックマークできないため後からページを再生することもない。 * ブックマーク可能なページは、setResponsePageにてインスタンスを指定してはいけない。このため、パラメータを伝達するには、それをPageParametersに格納したり取り出したりする小さなクラスがあれば便利である。 == 実装コード == |
パンくずリストの実現
wicket-extensionsにパンくずリストパネルが用意されているが、これは使い物にならない。 ここでは独自のパンくずリストの実装について考えてみる。
パンくずリストのそもそもの問題
パンくずリストを使って、一つの同じページに到達するのに別々のルートを通った場合の表現を行うのは非常に困難である。 また、経路途中の特定の状態を保持するのも困難である。以下の二つのパンくずリストを考えてみる。
トップ / 顧客一覧 / 顧客A
トップ / 製品一覧 / 製品B / 製品B購入者一覧 / 顧客A
いずれの場合も、現在顧客Aのページを表示しているが、そこにいたるまでの経路はそれぞれ異なる。このパンくずリストのいずれかのエントリをクリックすると、そのページを表示したいとする。
しかしこれは非常に難しい、例えば、今現在表示中の顧客Aのページがブックマーク可能であるとすると、そのブックマークは
http://localhost/customer?id=1234
ではありえない。なぜなら、これでは顧客Aのページということはわかるのだが、その途中の経路情報が一切無いからである。これをあえて表示しようとすれば、
トップ / 顧客A
となるしかない。もし前者の経路を表現しようとするなら、
http://localhost/?path0=top&path1=customerList&path2=customer&id=1234
などとしなければならないだろうし、後者の経路は
http://localhost/?path0=top&path1=products&path2=product&path3=buyers&path4=customer?id=1234
などという情報が必要である(パラメータはかなり適当)。これらの情報があって初めてブックマークされたページのパンくずリストが再現可能になる。
しかし、これを実現するのは極めて煩雑である。ページ遷移のたびに、そのパラメータとして前のページに与えられたパラメータを積み重ねていかなければならない。また、そこまでの必要性があるかどうかは疑問である。
もし、以下のように購入者一覧ページを表示中にその中から顧客Aが選択されたら、
トップ / 製品一覧 / 製品B / 製品B購入者一覧
以下のように顧客Aの「ごく普通のパス」に変更されてしまっても問題は無いと思われる。
トップ / 顧客一覧 / 顧客A
さらに、
トップ / 製品一覧 / 製品B / 製品B購入者一覧
のパンくずリストでは、途中の「製品B」というパスが再現されなければならないが、これもパンくずリストの記述を省略することによって対応すべきであろう。つまり、
トップ / 製品一覧
の状態で製品Bが選択されたら
トップ / 製品一覧 / 製品B
となるが、このページにおいて、製品Bの購入者一覧がクリックされたら、
トップ / 製品一覧 / 製品B購入者一覧
などと省略することにする。
ページの木構造
上に述べたように、ユーザの通った経路をパンくずリストとして逐一記録していくのは困難であるため、途中経路については以下の方針でいくしかない。
- 各ページは一つの木構造の中の固定的な位置を占める。
つまり、ページの構成は以下のようになり、
A +- B | +- C | +- D +- E +- F +- G
あるページを表示すると、そこからトップにいたるまでのパスが固定的にパンくずリストとして表示されるということである。また、
- ただし、途中のページについてはパラメータ付であってはならない(パラメータによって表示内容が変わってはいけない)が、最後のページ(パンくずリストの右端)については、パラメータ付でもよいものとする。
途中のページのパラメータについては(不可能ではないものの)保持するのは非常に煩雑になる。これに対して最後のページ(現在表示中のページ)についてはパラメータ付でもよい。これをブックマークして再生するとこのページを完全に再生できるし、途中のページのリンクもまた完全に再生することができる(パスが固定しており、パラメータが存在しない)。
ブックマーク可能なページの扱い
Wicketでブックマーク可能なページのクラスは、引数無しかあるいはPageParameters引数のあるコンストラクタが存在しなければならず、かつsetResponsePageの呼び出し時にはインスタンス生成を引数としてはならず、クラス(+PageParameters)を引数としてなければならない。
この制限はつらい。なぜなら、前のページでオブジェクトAを取得し、その詳細を表示させるためにそのオブジェクトAを渡すことができないからである。いったんオブジェクトAのID番号等を取得し、それをPageParametersの中に格納し、それと共にsetResponsePageを呼び出さなければならない。
この制限を緩和できないものか?例えば、オブジェクトAをコンストラクタ引数とし次のページを生成してしまっても、そこから逆にPageParametersを取り出せればブックマーク可能なURLが作成できそうなものだが、どうもsetResponsePageの挙動を変更することはできそうもない。このようなページのプログラムは以下のようにしておくとよいかもしれない。
public class HelloPage extends WebPage { public static class Parameter { private PageParameters params; public Parameter() { params = new PageParameters(); } public Parameter(PageParameters params) { this.params = params; }; public Parameter setId(String value) { params.add("id", value); return this; } public String getId() { return params.getString("id"); } public PageParameters getParams() { return params; } } public HelloPage(PageParameters params) { Parameter p = new Parameter(params); String id = p.getId(); .... } } .... setResponsePage(HelloPage.class, new HelloPage.Parameter().setId("1234").getParams());
パンくずリスト実装の方針
- すべてのブックマーク可能ページは単一の木構造の中のいずれかの位置に固定的に存在する。
- ただし、ブックマーク不可能なページはどこに現れてもよい。それらは、ブックマークできないため後からページを再生することもない。
ブックマーク可能なページは、setResponsePageにてインスタンスを指定してはいけない。このため、パラメータを伝達するには、それをPageParametersに格納したり取り出したりする小さなクラスがあれば便利である。