Sep 2006
らぼらぼ | Oct 2006 | Aug 2006
The spec of Legacy_Controller cache mechanism (2)
2006/09/27 | XOOPS Cube | Permanent link
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 は、そのキャッシュメカニズムを働かせることができません。
|
Alpha5 is available
2006/09/25 | XOOPS Cube | Permanent link
XOOPS Cube Legacy2.1アルファー5は現在、利用可能です。 アルファー5は多くのバグフィックスと私がアルファー4まで開発するのを忘れた新しい移植された特徴を含めます。 それらの特徴はXoopsFormテンプレート、はるかに良いキャッシュメカニズム、およびフルスペックの(?)ユーザ検索です。 これらの新しい移植された特徴は重要ですが、多くのフィックスが、より重要です。 これらのフィックスは多くのテスターによって報告されました。 私の友人に感謝します!

いくつかの問題がそこにあるので、私たちはアルファー5-aを開発しなければならないでしょう。 しかし、何もBetaの進歩を止めません。 プロジェクト・チームには、Legacyのための新しいXCube名前空間が既にあります。 アルファー5ブランチが発展しても、私たちはBetaブランチで進むつもりです。

ところで、昼休みに私がGmailを使っていたとき、gigamasterはgoogle talkで私に話しかけました。それは楽しい経験でした。 私たちはXOOPS Cube Legacyのパーミッション管理に関して話しました。 日本はまさに昼休みでしたが、彼の国は朝の時間でした。 私のボスが私を呼んだので、私はさようならを彼にうまく言うことができませんでした。 しかし、私は楽しかった。 Laugh

XOOPS Cube がフォークして以来、私は英語を勉強し始めなければならなくなりました。私の英語は非常に貧しいのですが、しかしそれは私のためのXOOPS Cubeの最大の収穫です。しかし、日本語の私のブログがただ機械翻訳であるので、日本版の私のブログはだめな品質になりました。 Winking
|
The spec of Legacy_Controller cache mechanism (1)
2006/09/24 | XOOPS Cube | Permanent link
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としてこれらの機能を交換するつもりです。 そして、標準のキャッシュモジュールはデフォルト機能を代表に提供するべきです。

既存のキャッシュファイルをきれいにする手段も重要です。
|
Cube Legacy in the final stage!
2006/09/23 | XOOPS Cube | Permanent link
私は、この数週間予想外に忙しく過ごしていました。家に帰らずに、仕事を続けていました。プロジェクト・チームの私の仲間もまた、私と同様に忙しいです。そのため、プロジェクト・チームは、またしても、スケジュールの遅れを公表しなければならなくなりました。しかし、よいニュースもあります。それは、多くの熱いユーザーが、これらの数週間の間、チェックとレビューを試みたので、XOOPS Cube Legacy がかなり多くのバグ・フィックスを得たということです。そして、自分たちの仕事に目処をつけたチームの一部の開発者は、2.1の開発スケジュールに復帰することが出来るようになりました。モジュール互換性をチェックすることは本当に多くの手間を必要とするので、私は互換性についてレポートの全てをチェックすることができていませんでした。しかし、私たちはそれができるようになります。

このポストに書かれているように、現在の開発ステータスは最終的なステージにあります。

XOOPS Cube Legacy は、 XOOPS Cube 層と Legacy モジュールから成っています。そして、 Legacy は XOOPS Cube のフィーチャー全てを使うというわけではありません。したがって、私は XOOPS Cube 層のデザインをテストするための Legacy でないもう一つのベース・モジュールを開発しなければなりませんでした。ご承知のとおり、それが Shade です。私は、 Shade において、プロジェクト・チームが Legacy で試行することができなかった主な仕様を決定しました。それらは、コンテキスト、アイデンティティ、プリンシパル、ロール、サービスと多くの変更です。しかし、 Legacy モジュールは、私たちのテスト・プロセスのために、 Shade より古い XOOPS Cube 層をキープしています。 Legacy の XOOPS Cube 層が常に更新されているならば、バグの原因を突き止めることは非常に困難です。そのために、 Legacy の XOOPS Cube 層は、しばらく固定されています。一方、シェイドの XOOPS Cube 層は、よく更新されます。つまり、プロジェクト・チームは、現在 Legacy と Shade という２つのプロジェクトを同時進行させているということです。

おそらく、最新の Cube と Legacy のマージは、多くの問題をもたらすでしょう。したがって、 Cube と Legacy がマージされるまで、我々は Legacy のバグの全てを固定するつもりでかからなければなりません。

我々の活発なゴールは、Legacy 2.1.0 です。このバージョンは、 XOOPS2 の機能の全てを模倣することができないかもしれません。たとえば、我々はカスタムブロックでプレビューをすることができません……。それは、良くはありません。しかし、 Legacy の将来のバージョンは、それが実装されているでしょう。つまり、致命的でない問題は、次のバージョンのための ToDo だということです。私たちにとっての Legacy の致命的な問題は、以下のようなものです：
  • 実行できない
  • 互換性がない
  • ヘルプがない
最初のリリースのために、私たちはこれらの３点をチェックしなければなりません。一緒に Alpha をテストしましょう。
|
Fatal mistake
2006/09/07 | XOOPS Cube | Permanent link
私は、 Alpha4-c でへまをやらかしました ...

Alpha4-c 、及び、 Alpha4-d のインストーラは、管理者のメールアドレスに関する不可欠のコンフィグレーションアイテムをインストールしません。私は、それを CVS で修正しました。従って、そのフィックスは、次のウィークリー・リリースに含まれるでしょう。

あなたの XOOPS Cube Legacy Alpha が Alpha4-c 、または、 Alpha4-d によってインストールされたならば、あなたはクリーンな DB と共に、再インストールしなければなりません。
|