The spec of Legacy_Controller cache mechanism (2)
Legacy のキャッシュメカニズムは、 1
つのコンテンツから、複数のキャッシュファイルを作成できます。blog
モジュールを想像してください。blog
ライターは、彼のエントリ上で編集アイコン、及び、削除アイコンを見ることができるでしょう。管理者にもなれば、更に特権的なコントロールアイコンを発見するかもしれません。すなわち、
1 つのエントリは、複数の見え方を持っています。従って、 XOOPS Cube Legacy
は、それぞれキャッシュを行わなければなりません。
そのために、そのコントローラは、アイデンティティや、現在のコンテンツがキャッシュ可能かどうかを示すフラグ等などの多くの情報を必要とします。XOOPS2
に基づく Legacy にはモジュールからそのような情報を得る方法がないので、コントローラは、
Delegate メカニズムを情報の交換に使います。コントローラが知ることを望むものは、下記です :
- コントローラは、このブロックをキャッシュすることができますか ?
- コントローラは、どのようなファイル名でブロックキャッシュを保存しますか ?
- コントローラは、モジュールのこのページをキャッシュすることができますか ?
- コントローラは、どのようなファイル名でモジュールキャッシュを保存しますか ?
そのコントローラは、 Delegate
を通じてこれらの問い合わせをします。そして、キャッシュモジュールは、キャッシュ方針を持つ関数を
Delegate
に加えます。サイト所有者は、キャッシュモジュールを交換する、もしくは、プリロードを加えることによってそれらのキャッシュ方針を調整し得ます。
What delegates are there?
checkEnableBlockCache()
このデリゲートは、現在の
URL
、及び、現在のユーザーがキャッシュに許可を与えられるかどうか、そして、そのコントローラがどのようなコンディションによってキャッシュするかをチェックします。Legacy
は、 Legacy_BlockCacheInformation
を情報交換のための特別な情報構造体として使います。なぜなら、プリミティブな変数のみを持つファンクションパラメータは、十分ではないからです。モジュールは、コントローラに報告するための多くの情報を持っており、情報の容易な交換には特別なクラス、または、構造を必要とします。
デリゲートを通じて、デリゲート関数は、特別なキャッシュ方針を情報構造体に設定し得ます。私は、次回それを説明するでしょう。
getBlockCacheFilePath()
このデリゲートは、保存するために、
$cacheInfo
のファイルパスを得るために使われます。これは、ユーザー関数がその方針に次第でユニークファイル名を決定するためにコントローラに干渉し得ることを意味しています。
checkEnableModuleCache()
これは、
checkEnableBlockCache() のブロックバージョン (
Legacy_BlockCacheInformation を情報構造として使う ) です。
getModuleCacheFilePath()
これは、
checkEnableBlockCache() のブロックバージョンです。
これらのデリゲートは、原則的に空っぽです。従って、サイト所有者は、キャッシュモジュールを通じてデリゲート関数を追加するべきです。言い換えますと、関数がこれらのデリゲートに全く加えられないならば、
XOOPS Cube Legacy は、そのキャッシュメカニズムを働かせることができません。