INTER-Mediatorでのページ状態の記憶の仕組みについて、幾つかの変更を行っています。変更前に動作の基本として、ローカルコンテキストは、ローカルストレージ（使えない時はクッキー）に保存をするようにしています。ローカルコンテキストには、ページファイル内にあるdata-im属性が「_@fieldName」のデータの置き場所を確保します。加えて、INTERMediator.addConditionメソッドでクエリーに追加する検索条件も、INTERMediatorオブジェクトのプロパティに見えるものの、実際にはそれをローカルストレージに保存しています。その結果、ページを開いた時にはローカルストレージは復元されるので、追加する検索条件も一度与えると明示的に消さない限りは、そのページに戻ったときに復元され、つまりは検索条件が常に保持されるように見える仕組みが組み込まれています。
ここで、ローカルストレージのキーに、URLを含めていましたが、URLのうちのクエリー部分は排除すべきかと考えました。例えば、ページファイルを開くときに渡すパラメータを与えて「page.html?id=101」などといったURLがある場合、ローカルストレージのキーに「page.html?id=101」までを含めるのか、「page.html」だけを含めるのか、どっちがいいのか（正しいのか？）を考えましたが、後者ではないかと思ったのです。クエリー部分があると、クエリーの内容によって以前の検索条件が消えるというのは、動作として正しくないと考えました。
ところがこうすると、こんな問題が発生します。例えば、page.htmlはクエリー部の情報を検索条件として付与するとします。「page.html?id=101」により、id=101という検索条件が加わり、ローカルコンテキストに保持されて残ります。そして、「page.html?id=55」をアクセスしたとき、どちらもpage.htmlなので、id=101という検索条件が残ったまま、id=55が付与されます。つまり、id=101 AND id=55というように、追加の検索条件が設定されてしまいます。idが主キーなら、検索されるレコードは0になってしまいます。これは意図しない動作です。
この問題には正解はないと思いますが、ロカールストレージのキーにクエリー部を含むURLを入れてしまうと、クエリー部によって、保持されるかどうかの挙動が変わってしまうことになります。一方、クエリー部を含めないでキーにすると、検索条件が追加されてしまって、意図しない動作になります。
そこで考えたのが、追加する検索条件については、マッチングをするということです。ローカルトレージのキーには、クエリー部は含めません。しかし、すでにid=101を検索条件として記憶している時に、addConditionメソッドで条件を追加するときには、条件のオブジェクトのfieldおよびoperatorプロパティが同一のもがあれば、その値のみを置き換えるようにします。id=55を追加すると、id=101とid=55のfieldおよびoperatorは同一なので、id=55の方だけが残るようにします。なお、こうした動作ではなく、従来と同様に単純に追加したい場合は、addConditionの3つ目の引数にtrueを指定することで、マッチングをしないで追加をするようにしました。ここまでをすでに実装しました。
そして、INTERMediator.clearConditionは、ローカルコンテキストの追加検索条件をクリアしていますが、同時に、ローカルストレージもクリアするのが正しいのではないかと考えています。すぐに実装は可能です。