The spec of Legacy_Controller cache mechanism (1)
XOOPS Cubeが、より多くのクラスを定義するので、Legacy_ControllerはXOOPS2
JPより重いです。 したがって、私たちにとって、強力なキャッシュメカニズムは重要です。
強力なキャッシュはしばしば問題を提起します。
例えば、キャッシュファイルが管理者のアクセスで作られるなら、匿名のユーザと登録ユーザは秘密の情報を見るかもしれません。
また、匿名のユーザーは登録ユーザのアクセスで作られているキャッシュを見ることができるべきではありません。
より多くの問題。 XOOPS2 JPはどんなURLのためにも見境無くキャッシュファイルを作ります。
存在しないIDと、同じデータを言い表す異なるURLのために、XOOPS2
JPはそれぞれのキャッシュファイルを作ってしまいます。XOOPS2
JPのcommon.phpがモジュールのキャッシュ方針を得るためにモジュールに接続することができないので。
XOOPS2
JPモジュールにモジュールのクラスのサブのクラスがあるなら、私たちはコントローラのために基底クラスにいくつかの新しいメソッドを加えるかもしれません。
しかし、XOOPS2
JPには、そのような概念がありません。common.phpはxoops_version.php以外のモジュールファイルをロードしません。
そして、xoops_version.phpには、キャッシュに関する仕様がありません。
どんなモジュールもそれらを定義していません。
したがって、私たちは任意であるとしてxoops_version.phpの定義を使用するかもしれませんが、Legacy_Controllerはそのような定義によるべきではありません。
さらに、多くのサイト所有者がキャッシュの戦略を調整したがっているので、私たちはそれを考えるべきです。
これらの状況のために、私たちはXCube_Delegateを選ぶべきです。交換可能キャッシュメカニズムを実行するのを可能にするために。
Legacy_Controllerがモジュールからどんな情報を得たがっているかは、明確です。
したがって、私たちは、Legacy_Controllerに新しいメソッドを加えて、次に、Delegateとしてこれらの機能を交換するつもりです。
そして、標準のキャッシュモジュールはデフォルト機能を代表に提供するべきです。
既存のキャッシュファイルをきれいにする手段も重要です。