lablab.jp （日本語版）

Cube の設計は OGRE をベースにしています。私が Cube (Shade2 という名前だった) のデザインに手をつけ始めたとき、私は PHP と Web アプリケーションを十分に習得していませんでした（今もですが）。そこで、私は私が普段扱っている設計を Xcube に持ち込みました。それはシーングラフの概念（特にOGRE）です。

この頃、私は Shade がそのまま XCube になるとは考えていませんでした。しかし、私は次のような考えを持っていました。

フレームワークなし

この当時、日本の PHP プログラマはフレームワークについてよく議論していました。そして、「フレームワーク」は日本人にとって特別な意味を持ち始めていました。日本人はよく日本語と英語を使い分けるため、「フレームワーク」はその邦訳である「枠組」とは異なるものになっていました。それは IT プロフェッショナルたちにとって重要な議論であったと思われます。しかし、私には普通でない状況に感じられました。私はそれに巻き込まれたくありませんでした。以上のことから、私は XCube はフレームワークを持つべきではないと考えました。

マルチレンダーターゲット

デザイナーはテーマフォーマットや CSS を問題視しています。しかし、これは一種の宗教論争です。私は、これは複数のレンダラによって解決可能なため、 XCube がこの手の論争に加わるべきではないと思いました。しかし、新しいフォーマットは既存のモジュールやテーマに悪影響をもたらします。私たちは同時に異なるフォーマットを使うことができ、最終出力はそれらの結果を含んでいることができるべきです。3Dアプリケーションはよくそのような目的を持ちます。私はレンダーシステムとレンダーターゲットの概念を XCube に持ち込みました。

構成

XCube の構成は .ini ファイルによって決定されます。それは DI ではないかといった人がいます。しかし、これは DI ではありません…なぜなら、 XCube はプロフェッショナルの世界でホットトピックスとなっていることに首を突っ込むつもりはないからです。実は、このプロセスも OGRE をベースにしています。 OGRE は換装可能なマネージャで構成されています。そして既にそれらのマネージャとして使用可能な多くのプラグインがあります。開発者は cfg を編集することによって、その組み合わせを決定します。これはユーザーがプログラムの初期段階に影響を与えることができる唯一の手段です（ソースコードの直編集を除けば）。 OGRE は「換装可能」というコンセプトを示すことで、「万人が納得する設計とは何か？」という不要な議論に遭遇しなくなりました。

換装

XCube はウェブサイトを実現するための具体的な関数を持っていません。これも OGRE のコンセプトです。 OGRE は非常にコンパクトなエンジンです。それは力学、AI、地形、そして BSP を持っていません。OGRE の開発が始まった頃、そのようなエンジンは常識では考えられませんでした。「エンジン」とは FPS を速やかに実現するために多くのフィーチャーを実装していなければならないモノだったからです。しかし、他のいくつかのエンジンは、多くの達成課題や多くの論争を解決することができずに、開発が止まり始めました。その間にも OGRE はその進捗を維持しました。

たとえば、あるエンジンにおいて、あなたが BSP の処理に納得がいかなかったとしても、ソースコードをいじらない限り組み込みの BSP 処理を変更することはできません。 OGRE はそのようなケースに対して異なる道を示しています。「換装」は「唯一無二の標準」を否定します。 OGRE において、あなたは異なる BSP を開発することが可能です。同じことが XCube でも言えるのです。この特徴は Wii 的であると呼ぶこともあります。

私は、長い間、オープンソースの考え方がお気に入りでした。しかし、ここ数年、私は、私の周辺のオープンソースに限定して、いくつかの疑問を抱くようになりました。昨日、私は、同僚とそれについて雑談する機会を持ちました。私の勤め先は、オープンソースについて何の関心も持っていません。しかし、私達には、オープンソースに関して共通のエキサイティングな経験がありました。それは Doom 、そして Quake です！　これらのGPL版は、私の記憶に残る真実のオープンソースであり、私の原点でした。この価値観は、私が XOOPS 日本コミュニティと相性が悪い原因かもしれません。しかし、活動的ユーザーであれば、なぜ私が Quake にそれを見いだしたか理解を示すでしょう。

日本の XOOPS コミュニティの周りには、「オープンソースとは何か？」という議論があります。オープンソースは、単にコンセプトのあるライセンスにすぎません。しかし、その精神の解釈について、多くの人々は、それぞれ異なる意見を持っています。

私がオープンソースにおける新米の活動家だったため、私は、この議論についてしばらく自分の意見を持ってきませんでした。そして、日本オープンソースコミュニティの一部の先輩方は、オープンソースの決まり事について私に指導してくれました。面白いことに、皆さんが教えてくれた「決まり事」は人によって言うことが全部違っていました。これは、（ライセンスを除けば）統一的な不文律などは存在していないことを意味しています。オープンソースは、活動的ユーザーを束縛する行動制約の集合ではなく単にライセンスです。

私は、行動を伴わない解釈議論が好きではありません。それは、一種のシミュレーションであり学術的な活動です。私がオープンソースに参加した理由は、大学の代わりにディベートの授業を受けることを望んだからではありません。スポーツ討論をするためだけに、スポーツクラブに入る人はいないでしょう。私は、実際に何かをするために、この世界に入りました。ですから、私は机上の空論で議論をしたいと思いません。当初私は、日本の文化の下では、おしゃべりだけの人間は誰からも嫌われると信じていました。しかし、私は、どういうわけか XOOPS Cube 日本における少数派の側にいます...

それゆえに、私は、国際コミュニティに期待しているし、英語をもっとうまく使いたいと思っています。

私は日本が嫌いではありません。オープンソースに関しては合わないと思って入るだけです。

私にとって最も良いオープンソースプロジェクトは何か？　それについて、私は、模範的回答として gcc を挙げるべきでしょう。しかし、それは私の本当の真の意見ではありません。間違いなく、私にとっての最も良いオープンソースプロジェクトは、「 Quake2 」です。私は、 i.d. ソフトウェアがそれを公開した出来事を忘れることができません。それは、エキサイティングな出来事でした。私は、ソースコードを変えて、そして、他の人たちによって変更されたカスタム Quake を手にいれることに夢中になりました。それは、まさに自由であり、そして、その自由は、一般人の活動によって満たされていました。世界は、美しく、エキサイティングでした。

その経験は、オープンソースにおける私の原点です。私は、 XOOPS Cube が楽をする場所ではなく、エキサイティングのための場所であってほしいと思っています。私の意見は、与えられた役割を果たすことを望む一部の日本人によって嫌悪されるでしょう。しかしながら、私は、結局、オープンソースは彼らの希望を満たさないと思います。オープンソースは、ライセンスによって保証される心の自由です。プロプライエタリのサブセットではありません。ですから、私は、日本から国際グループへプロジェクトを動したいと思っています。なぜなら私は外国の方が積極的な人々が多いと信じているからです。

私は、オープンソースについての議論をすることは嫌いではありません。しかし、実行動なしで議論のみをすることは、無益な時間です。私は、なぜ多くのユーザーが実行動より議論を好むか理解できません。

ところで、 GPL Quake は、中央集権組織を持っていませんでした。もちろん、 XOOPS を Quake と比較することは、ナンセンスです。しかし、オープンソースを突き詰めれば、「自由」に行き着くはずです。私の疑問は、この意見への反対者がよその例を挙げるばかりで自分では何もしないことです。

ハッピーニューイヤー !　そして、私は、 2006 年と日本公式サイトへさよならを言いました。 xoopscube.jp は新しいモデレータを得て、そして、公式のサイトであることを止めたのです。それは、重要な前進です。なぜなら、日本のユーザーは、強迫観念から解放されたからです。誰もが、公式サイトとは何か？といったことを考えずに自分自身の信念の下で実行動できるのです。

あなたは、日本人は決して実行動に出ないと思うかもしれません。確かに、xoopscube.jp は、行動なけれども要望ありのユーザーから成る不活発性集団のように見なされます。日本人は出る杭を打つ習性を持つ動物です。ですから、この国で、すすんで出る杭になろうと思う人はいません。しかし、活動的ユーザーは、 xoopscube.jp の縮小計画を理解し、そして、多くのプロジェクトを始めました。私は、それらのうちいくらかを、ここにリストしました。

中央集権主義を愛する一部のユーザーは XOOPS Cube が消滅するだろうと警告します。彼らは、他の有名なオープンソースプロジェクトと同様に、コミュニティをコントロールすることができるかどうかを試したがっています。とても良いことです。彼らは、開発チーム抜きで自分自身の政治的手腕を試してみることができる自由を手にしました。あらゆる価値観は、なんの許可もなく存在するものです。自身の信念の下で行動してください。

たとえ XOOPS Cube が日本で将来消滅するとしても、私は、それは全く問題ない、と思います。なぜなら、歴史は、人々の行動の結果だからです。私達ができる唯一のことは、私達の行動の結果を受け止めることです。行動しないことは、望みを持たないことに等しいのです。

XOOPS Cube は、国家でもなければ、政府でもなく、地球でもなければ、宇宙でもありません。すなわち、これは命がけで必要とされるものではありません。ですから、滅亡可能な XOOPS Cube で、私達は、私達が、目的実現のために行動し、それを共有することができるフロンティアであるかどうかを試すことができるのです。私達が真に人間であるかどうかを試すことができるのです。

いくらかのモジュールは、 Cube Legacy 2.1 上で動作することができないでしょう。原因のうちの 1 つは、継承クラスのコンストラクタがその基底クラスのコンストラクタを隠蔽することです。 Marijuana 氏は、この問題を指摘しました。しかし、私が思うに、そのようなコードを書いた開発者は、それを隠蔽することを意図していなかったでしょう。つまり、彼らは、 PHP の、ある仕様を知らなかったのではないかと思います。

class A {

  var $mFuncB;



  function A() {

    $this->mFuncB =& new XCube_Delegate();

  }



  function funcB() {

    $this->mFuncB->call();

  }

}



class B extends A {

  var $mFlag;



  function B() {

    $this->mFlag =& new Flag();

  }

}



$instance =& new B();

$instance->funcB();

多くの開発者は、上記プログラムにおいて全く問題を感じないでしょう。しかし、 funcB() が呼ばれるとき、そのプログラムは、致命的エラーを上げます。mFuncB が初期化されないことが、その原因です。実は、他の一般のプログラミング言語と異なり、 PHP 言語では基底クラスのコンストラクタは自動的に実行されません。私は何度もこの問題にはまりました。

あなたがコンスラクタを書くとき、あなたは、規定クラスのコンストラクタを parent キーワードを使って明示的に呼ばなければなりません。

class B extends A {

  function B() {

    parent::A();

  }

}

それは、奇妙なコードです !　しかし、あなたが継承クラスに特定の初期化コードを持っていないならば、あなたは、コンストラクタを省略することができます。空のコンストラクタは必ず parent を呼ばなくてはいけないので、この仕様は、非常に有益です。私は、コンストラクタをしばしば省略します。

XOOPS Cube Legacy 2.1 において、いくらかのクラスは、それらのコンストラクタに追加の初期化コードを持ち始めました。従って、サブクラスが基底クラスのコンストラクタを隠す場合、それは、不互換性問題の原因であるかもしれません。開発者は、 PHP の仕様、及び、他の一般の言語の間の差異に注意する必要があります。

基底クラスのコンストラクタは、隠蔽されるべきでありません（たとえ PHP でそれをすることが可能であるとしても）。従って、 XOOPS Cube のコーディング規則は、モジュール開発者のために、この問題に言及するでしょう。

• PHP において、あなたは、必ずしも C++ 等々のようにコンストラクタをを書く必要がありません。
• あなたがコンストラクタを書かなければならない場合は、他の言語との融和性のために、コンストラクタの先頭部分へ parentコールを挿入してください。

私は、プロフェッショナルのウェブプログラミングを知りません。しかし、コンストラクタを隠蔽することは、 PHP プログラマのための一般のチップではないでしょう。継承クラスのコンストラクタがその基底クラスのコンストラクタを隠蔽することは、継承の否定です。

I and Mr. nobunobu take a business trip nearly every week this month. That's tough schedule. And it's the cause which makes development stop. After we will return from our business trip, we will release Beta 4 as the last release of this year. We already posted the change log and Mr. ayumi prepared the release news.

RC will be released next month. But, I have to go to the development camp of my company from Dec 30th to Jan 10th. Therefore, I can not touch XCube RC while I'm in the camp. The dev team will clear incomplete tasks as 'known issue'.

I don't have been able to develop XCube enough this month. I had few hours to do it as well as all other members. These days are final big test for the first dev team. In this final process, we will do the following:

• We will move the official project page to sourceforge.net.
• We will make the dev team open under some international conventions.
• We will delegate the community management to hot users. Our opinion is that developers don't need to be leader of the community.

Until now, we have needed Japanese closed dev team for rapid development. But, we will be able to explain Cube's concept through source code in the near future. And, we will not need to discuss complex subjects in English. In other words, we will become able to finish closed team and Japanese team in the same time.

Because many Japanese like better the power game than open source development, our way will be discussed. I think Japanese people have freedom to do the power game. But, developers don't have any impositions to join it. In other words, developers have freedom to wish not to do the power game. Each freedom should be respected.

And, they who love the power game should not get the authority of the international project, just because they are Japanese people. XOOPS Cube is not for Japanese only. And, Japanese users are not special in XOOPS Cube. But, I think this concept brings true freedom to Japanese users at the last time.

xoopscube.org doesn't intervene in the administration of each community. We want to be friend of French and others, but we are not administrators in them. xoopscube.org is not the centralism to control others. Also Japanese community will get freedom.

If there are not hot users enough in Japan, XOOPS Cube community in Japan will be death. If there are hot users enough in Japan, XOOPS Cube community in Japan will evolve under free sky.

All results will be guided by not developers' impositions but users' zeal. I will receive any results Japanese users will choose, even if it is destruction.

あるところに、ビギンズという男がいた。彼はスーパーマーケットへ出掛けて、カップヌードルを見つけた。その製品のラベルには「あなたは５分間でこれを料理できます」と書いてあり、そして値札には「たったの１００円」と書かれていた。ビギンズはこの食料品を購入し、帰宅してその調理にとりかかった。

しかし、ビギンズは、カップヌードルの調理に必要なお湯を準備していなかった。そのうえ、そもそも湯を沸かすためのケトルを持っていなかった。彼は、店に戻り、そして、さらに30分と2,000円を支払ってケトルを購入した。

こうして、カップヌードルはできあがったが、ビギンズが箸を持っていなかったために、食べることができなかった。彼はついに激怒し、店に戻ると、店員にこの食料品の不当表示について抗議を始めた。


ビギンズ: このラベルには５分間でこれを調理できると書いてある。しかし、湯がなかったら、５分間で調理することはできないじゃないか！

店員: お客様、ラベルをよくお読みになっていただければ分かるのですが……「お湯を加えて５分間」とあります。

ビギンズ: でも５分だよ、５分！　５は赤い色で強調されている。誰がそんな必要条件まで目をやるというんだ！　それにレジ係が箸をくれなかったから結局食えなかったんだぞ！

店員：は、箸？　お客様、なんのことでしょうか？

ビギンズ：このラベルは、「５分間で調理可能」と書いてある。言い換えれば、誰でも、簡単になんでもできるってことだろ！　しかし、レジ係は箸をくれず、私は食えなかった！　これは不当表示だ！

店員: ちょ……お待ちください、お客様。このラベルは「なんでも簡単にできる」なんて書いていません。このラベルはお湯が準備済みの場合の調理時間について言及しているだけです。

ビギンズ：でも５分だよ、５分！　５は赤い色で強調されている。この文面だと、初心の料理人なら「俺は何でも簡単にできるんだ」って期待するだろ！

店員：私はお客様が小学校から人生やり直すことを期待しますが。。。

ビギンズ：さらに、この値札は「たった１００円」と書いてある。でも、私はケトルと箸を買うのにさらに2,100円使ったんだぞ！　私はこれが不当表示であると言わざるを得ない。

店員：。。。

ビギンズ：私はこの不当表示を警察に申告するつもりだ。

店員：私も警察呼んでいいでしょうか？


日本のコミュニティは「PHPおよびMySQLが利用可能なサーバであれば、約 5 分でインストールでき、直ちに当サイトのようなユーザ登録型コミュニティサイトを立ち上げることが可能です」と書かれているウェルカムメッセージを取り除きます。ユーザーが「なんでもできる」と誤解してしまうためです。

このメッセージはCube以前の別の人々によって作られたものですが、私はこのメッセージをCubeのリリースまで保持すべきだと提案しました。なぜなら……私は日本が高い識字率を持つ先進国の一員であると思いこんでいたかったからです。(^^;

私が限定的なネットワーク環境の下であまりに忙しいので、私は現在ソースコードにさわることができません。XOOPS Cubeを開発するために、私は私の家に戻らなければなりません。しかし、私が毎晩私の家に戻ることは、不可能です。それに加えて、私が家に戻って来るとき、私には新しい服を準備するためのわずかな時間がありますが、他の仕事を行うことはできません。

現在、のぶのぶさんがフィックスとパッチをしています。しかし、彼も非常に忙しいです。

12月は、日本で最も忙しい月です。日本人は12月のことを「師走」と呼びます。「師走」は偉大な師匠も若者と同じように仕事を終えるためにあちこち走り回らなければならないことを意味している古語です。

ディベロッパー・チームのメンバーは、彼らの会社で彼らの仕事をしなければなりません。しかし、彼らはコミュニティにチェックすることをリクエストしました、そして、コミュニティはそれをするためにその最善を尽くします。我々は、RCの代わりに新たなベータを得るでしょう。

ところで、日本のサイトは、XOOPS Cubeの無政府主義において特別な公式サイトです。しかし、サイトは無政府主義に従い、そのサイト名からタイトルを取り除くでしょう。そして、ディベロッパー・チームはsourceforgeへ移動するでしょう。彼らはRCと同タイミングでそれをすることを望みました。しかし、彼らは独立した計画として計画を取り扱うかもしれません。少なくとも、日本のサイトは、他の国のサイトと同様にサイトのうちの1つであるというその更新計画を発表します。

私がクリスマスに家に帰ることがありえるように、ちょっとあなたの指を横切っておいてください。

このサイトは、私のエントリによって作られたサンプルのコレクションです。そのリポジトリは、 Cube Legacy の最新のバージョンで動作可能な状態をキープされているサンプルを持っています。

私は、今まで多くのサンプルを書きました。しかし、それらの大部分は、最新のバージョンにおいて動作しません。なぜなら、 Cube Legacy は、その仕様を変えたからです。私は、それらとそれらのドキュメントをフィックスする協力者を必要とします。パッチ追跡者システムは、 XOOPS Cube プロジェクトのそれと同様に、あなたのパッチを受けます。そして、あなたが母言語の翻訳をコントリビュートできるのであれば、 UTF-8 でメールを私に送ってください。私の電子メールアドレスは、 minahito at users.sourceforge.jp です。

Installer

このモジュールは、 PM と交換されますので、このモジュールが PM の現存するデータを移動させることができればベストです。そのような目的のために、 XOOPS2 ではモジュール開発者は onInstall スクリプトを使用します。Legacy 2.1 では、カスタムインストーラが利用可能です。カスタムインストーラは、 xoops_version において宣言された特定のクラスです。通常、そのクラスは、コントロールパネルにおけるインストール機能によって使われるインストーラクラスのサブクラスです。

$modversion['legacy_installer']['installer']['class'] = "Installer";

これは、正式なクラス名ではありません。正式なクラス名は、この宣言と dirname によって生成される合成名です。それは {Dirname}_{class} です。この場合、正式なクラス名は、 "Messgae_Installer" になります。そのクラスは、 admin/class/{class}.class.php において定義されなければなりません。

命名規則は、複写可能なモジュール、及び、 D3 モジュールのためのいくらかのオプションや例外を持っています。詳細は Legacy_ModuleInstallAction のコメントを見てください。

モジュール開発者は、カスタムインストーラによってインストールプロセスの全てをコントロールすることが可能です。onInstall より優れた仕様は、柔軟性、及び、ロギングです。インストーラクラスは、そのメンバープロパティとしてログインスタンスを持っています。それを通じて、このモジュールは、マイグレーションに関するメッセージをユーザーに示します。これらのメッセージは modinfo.php において定義されています。

Kernel handler hook

プライベートメッセージは、 Legacy 2.1 の任意の仕様です。しかし、それは、他のフィーチャーにおいてはポピュラーな仕様です。例えば、悪名高き XoopsMultiMailer は、メール、及び、メッセージを抽象化します。同じく通知機能は、プライベートメッセージを使います。これらのクラスは、メッセージを送るためにカーネルのプライベートメッセージハンドラを使います。従って、このモジュールはこのハンドラをフックしなければなりません。どうすればよいでしょうか ?

答えはデリゲートを理解することにあります。カーネルのハンドラは、フライウェイトパターンの一種である xoops_gethandler() を通じて取得されます。 xoops_gethandler() は、デリゲートイベント "Legacy.Event.GetHandler" を備えています。従って、プリロードで関数をこのイベントに加えることによってそれをフックすることが可能です。それによって、 xoops_gethandler() は、プライベートメッセージハンドラを得るためのリクエストに対して、このモジュールのアダプタクラスを返します。それは、興味深いです。kernel/privmessage.class.php を見てみてください。

Note

xoops_gethandler() は、キャッシュを持っています。だれかが preBlockFilter() の前にプライベートメッセージハンドラを得るならば、イベントは、プライベートメッセージハンドラのために、二度と呼び出されないでしょう。

プリロードをプライマリプリロードとして指定可能な状態につくっておくことはよい解決策になります。

開発チームはRCの基準が何であるかに関して議論しています。 多くの開発者がRCバージョンに固定APIを要求するでしょう。しかし、それをするためには、多くの実例が必要です。この年末に、それらを開発するために空き時間を保つことはかなり困難でしょう。

しかしながら、私は、1つのバグと3つの設計ミスを、昨日のあの程度のサンプルモジュールを通じて発見しました。ですから、実例を開発するということは本当に重要です。 XOOPS Cube Legacy2.1には、ソフトウェアデザインの他の問題があるかもしれません…

しかし、十分時間のある人なんていません。非常に難しい問題です。

私は、このサイトの XOOPS 開発者リングの次のリンクを tohokuaiki 氏に変更しました……といいますのも、 gusagi 氏のサーバは、壊れてしまったからです。私は、彼のサーバに哀悼の意を表します。

さて、ここに Legacy 2.1 のためのサンプルモジュールがあります。「message」モジュールは、進歩したプライベートメッセージモジュールです。それは、送信ボックス、草稿ボックス、プレビューを可能にします。

あなたは、このサンプルによって次のものを学ぶでしょう :

• どうやって Legacy 2.1 のカーネルハンドラをフックするか
• ログと共にある Legacy 2.1 時代におけるインストールスクリプト
• User-Control-Event の応用
• Legacy 2.1 のための共通インタフェースとしての仮想サービス
• cubson 0.52.3 のサンプル（あなたが cubson ユーザーであるならば）
• そして、 Cube の換装コンセプトの一端

あなたは、このモジュールを動かすのに Cube Legacy 2.1 の最新のスナップショットを必要とします。ダウンロードページからこのモジュールを得てください。

インストール方法

1. あなたが pm モジュールをインストールしたならば、それをアンインストールしてください。
2. このモジュールをインストールしてください。
3. 現存するメッセージは、インストールスクリプトによって自動的にマイグレーションされます。

昨日のテスト版 UTF-8 言語マネージャは、 global.php を UTF-8 に変換していませんでした。nobunobu さんが、パッチを私に送ってくれました。私は、 nobunobu さんのパッチをマージすることによってバージョン 0.02 をアーカイブしました。

言語マネージャが global.php を変換しなければならないので、 global.php において定義されるオリジナルの _CHARSET を使うことは、不可能です。そこで、言語マネージャは、設定ファイルの情報、または、言語マネージャクラスの組込固定情報を使うようになりました。

Verison 0.02 では、組込固定情報として日本語 ( EUC-JP ) 、及び、韓国語 ( EUC-KR ) があります。設定ファイルによってこれらの情報をオーバーライトすることが可能です。もちろん、他の言語を加えることもまた可能です。

[Module_Utf8LangMgr]
multibyte=chinese,korean,japanese
chinese=big5
korean=...

私は、 Legacy System 2.1 用の汎用 UTF-8 Language Manager を開発しました。あなたはダウンロードページからこれをダウンロードできます。これは、まだテストバージョンです。そして、あなたはこのモジュールのアクションフィルタがモジュールプリロードより早く働かなくてはいけないため、特別な方法によってこれをインストールしなくてはいけません。しかし、それは、非常に容易です。

Step1... 事前条件の確認

このモジュールは、 UTF-8 エンコーダとして Utf8LangMgr_LanguageManager をあなたのサイトに提供します。しかし、このモジュールは、インストーラには何の影響も与えません。従って、あなたは、自分で UTF-8 データベーステーブルを作成しなければなりません。しかし、各モジュールの言語ファイルを変換する必要はありません。

Step2... モジュールの配置

他のモジュールと同様に、 /modules にこのモジュールのディレクトリを置いて下さい。

Step3... 設定の変更

Legacy パッケージの構成は、 /settings/site_default.ini.pnp に書かれています。あなたは、そのファイルに優先プリロードとしてこのモジュールのプリロードを指定しなければなりません。XOOPS Cube がオーバーライド設定機能を持っているので、 site_default.ini.php を直接修正する必要はありません。/settings 内で site_custom.ini.php を作成して、そして、下記のように書いてください。

<?php
/**

[Legacy.PrimaryPreloads]
SetupUtf8LangMgr=/modules/Utf8LangMgr/preload/Primary/SetupUtf8LangMgr.class.php

*/
?>

完了です。トラブル報告は xoopscube.org フォーラムのスレッドにお願いします。

覚え書き

あなたのサイトがマルチバイト言語を用いるならば、あなたは、 charcode をこの言語マネージャに通告しなければなりません。私が知っているいくらかの言語の Charcode は、このモジュールの優先プリロードに含まれます。しかし、それが自動的に解決されないならば、あなたは、 site_custom.ini.php に記述を加えなければなりません。

[Module_Utf8LangMgr]
japanese=EUC-JP
korea=...

このファイルにおける設定は、自動ソリューションより早くこの言語マネージャに適用されます。

Legacy モジュールはモジュールアップグレードのための新しい仕様を実装しました。 XOOPS2 JP において、アップデートスクリプトの仕様がアップグレードステップに対して十分ではなかったため、モジュール開発者は彼らのモジュールを自在にアップグレードすることができませんでした。モジュールの歴史の上では、多くのことが変更されます。 DB テーブルへの新しいフィールドの追加、モジュールへの新しいブロックの追加、コールバック関数の改名やリソースの除外…… XOOPS JP はこれらの情報を厳密な定義なしで自動的に更新しようと試みます。すなわち、そこに厳密なルールはありません。そのため、モジュール開発者は XOOPS2 JP がどのようにモジュールを更新するかを調べるために XOOPS2 JP を探索しなければなりませんでした。

ベータ３で、 Legacy System モジュールは vBulletin ライクな段階的アップグレードモード (phased upgrade mode) を導入しました。このモードでは、アップグレードはマイルストーン・バージョンに制限されます。たとえば、以下のような悪魔的なチェンジログを持つモジュールがあるとします。

• v0.10 初版 (varchar(255)の value フィールドが DB テーブルに存在)
• v0.20 新たに整数フィールド 'value2' をテーブルに追加
• v0.30 既存フィールド 'value' を DB テーブルから削除
• v0.35 'value2' を 'value' に改名

この悪魔的なチェンジログに対して、あなたはどのようにコールバック関数を書きますか？　不可能ではありませんが、それはとても困難です。大半のプログラマは XOOPS2 JP のよくないスペックと格闘することに時間を浪費したいと思わないでしょうから、大胆な変更は失われていきます。

段階的アップグレードは、アップグレードを複数のプロセスに分割することを可能にします。この例であれば、

1) v1.0 -> v2.0 upgrade
2) v2.0 -> v3.0 upgrade
3) v3.0 -> v3.5 upgrade

この方法により、ユーザーはいかなるバージョンからも正常に最新版へアップグレードすることができます。そして、モジュール開発者は Legacy System モジュールの自動的不正確アップグレード機能を抑制することができます。

モジュール・アップデート機能はベータ３より Legacy_PhasedUpgrader クラスを使用します。モジュール開発者が段階的アップグレード(phased upgrade)を望む場合、彼は Legacy_PhasedUpgrader のサブクラスを宣言しなければなりません。彼はクラスの全メソッドをオーバーライドすることができますが、 Legacy_PhasedUpgrader はモジュール開発者が段階的アップグレードを容易に実現できるように設計されています。したがって、マイルストーンバージョン番号とそのバージョンへのコールバックメソッドを定義するだけでよいでしょう。

Example Module "upgradeTest":

1. まずはじめに、 upgradeTest-0.10 をインストールしてください
   
2. 次に、 upgradeTest-0.35 をアップロードし、それからこのモジュールをアップデートしてください。
   
3. あなたは三段階でアップグレードしなければならないでしょう。

この例のチェンジログは上の悪魔的チェンジログです。しかし、あなたは以下のようなステップで正確にアップグレードを達成するでしょう。

(1) upgradeTest 0.10 -> upgradeTest 0.20 (Phased Upgrade) -> (2)
(2) upgradeTest 0.20 -> upgradeTest 0.30 (Phased Upgrade) -> (3)
(3) upgradeTest 0.30 -> upgradeTest 0.35

upgradeTest-0.35 はモジュール開発者のための良いサンプルです。

インサイドストーリーといっても、これは別におおげさな話ではありません。先週の土曜、私は OSC2006/Fall (Open Source Conference 2006 tokyo Fall) に出掛けました。これは日本オープンソース界でもっとも有名なイベントです。多数の企業とコミュニティがこのイベントに参加しました。彼らはブースを開き、講演を行いました。

XOOPS Cube 日本コミュニティも参加しました。 XUGJ (Xoops Users Group Japan) メンバーがブースで出展しました。開発チームからは、私と nobunobu さんがスピーチを行いました。このインサイドストーリーはそのスピーチに関するものです。

先週の金曜日、翌日のためのプレゼンテーションファイルはまだ完成していませんでした。初代開発チームはもうすぐその役割を終えるので、 OSC2006/Fall は開発チームにとって最後のイベントです。次の OSC からは、モジュール開発者が主役と中核を担うようになります。したがって、私は自分の意見のすべてを話すつもりでした。私はプレゼンテーションファイルを完成させるために最善を尽くしました。そして、 AM 3:30 、それは完成しました。ファイルは私の mac mini に格納され、 mac mini は私のバッグに格納されました。それから私は睡眠を取りました。

翌日、私は繰り返し mac mini の VGA アダプタを確認していました。７月の XTC2006 イベントで、私は VGA を忘れたことがありました。そのため、 XTC スタッフは私のスピーチが始まる前にショップに駆け込まなければなりませんでした。私は同様の失敗を恐れていました。私はバッグの中で mac mini の VGA アダプタの存在を確認すると、新宿へ出発しました。そのとき、 mac mini の AC アダプタは私の部屋の床の上にありました……

私は特急列車に５ドルを払うと、誰よりも早く講演会場に到着しました。それから、私は自分のスピーチの準備を始めました。もちろん、その準備は終わりませんでした…… mac mini は AC アダプタなしではブートアップできないからです。信じられない！

私には２０分しかありませんでした。もちろん、 AC アダプタを取りに帰宅することは不可能です。開発チームのメンバーは、私が ML にいくつかの古いバージョン投稿した PDF ファイルを使うことを提案しました。他に方法はありません。しかし、講演会場ではネットにつなぐことはできませんでした。私はブースへ行ってダウンロードをお願いしました。しかし、ブースでも、誰もネットにつなぐことができていませんでした。 gusagi さんは彼のモバイルカードを使ってファイルをダウンロードしてくれました。そのおかげで、私はスピーチ用の PDF ファイルを手にいれることができました。

この準備のために私は１９分を費やしました。私は講演会場へ駆け込みました。私のスピーチは何の問題も（そして何のアニメーションも）なく終了しました。

それから、私は次のスピーチのために AC アダプタを取りに帰宅しなければなりませんでした……なぜなら、次のスピーチのための PDF ファイルは作られていないからです。私はそれのために２時間を費やしました。

ところで、私は３週間にわたり風邪をひきつづけています。そして、このトラブルで病状は悪化しました。再び講演会場に到着した時、私は２つの薬を使いました。恐らくこの２つの薬の組み合わせは私にとって悪かった。体調は最悪になりました。しかし、お客さんは私の２回目のスピーチを楽しんでくれました。

私の持ち時間をこのトラブルで失ってしまったことと、体調が悪すぎたので、私は他の OSS のブースやスピーチを訪問することができませんでした。新しいページが、私のトラブル伝説に加えられました。

しかし、私は OSC2006/Fall に加わったことをうれしく思っています。あなたは私のスピーチの PDF ファイルここで見ることができます。

誰だこのくそったれクラスを書いたのは！？　俺だ……

最近、私はこのタスクに挑戦しています。私はこのタスクを Beta 2 で仕上げることが出来なかった。しかし、 Legacy_AbstractModuleInstaller はモジュール開発者向けに設計されていないので、これは少し難しい……私はこのクラスを掃除することにしました。

もしこのタスクが達成されれば、モジュール開発者は vB ライクな段階的アップデートを使うことができるようになります。私は Beta 3 までにそれを仕上げて、モジュール開発者にレビューをお願いしなくてはいけません。

私は、「XOOPS Cube Legacy キックスタートガイド」を Legacy モジュールのヘルプに加えました。KICK START は、私のお粗末な英語で書かれています。心配はいりません。私の友人は、それを編集してくれます。

ビギナーは、このキックスタートで XOOPS Cube Legacy 2.1 の基礎的な使用を学ぶかもしれません。しかし、ひとつ問題があります……

ありえないことに、KICK START は、「ニュース」モジュール & 「newbb」モジュールを説明に使います !　D3 modles ( bulletin2 、 d3forum ) が私の英語では説明できないからです……。それに、 D3 モジュールは、特別なディレクトリツリーを必要とします。そのため、私は、最初のチュートリアルにそれについて書くことに躊躇してしまいました。

おそらく、 bulletin1 、及び、 xhnewbb を選択するべきでした。しかし、これらのものは、レビューをされるでしょう。私達にとって重要なことは、レビューのための標準のチュートリアルの草稿を得たことだと思います。

Description

Legacy_ControllerはXoosModueインスタンスと同様にXoopsBlockインスタンスを直接使用しません。 ブロックプロセスでは、Legacy_ControllerはLegacy_AbstractBlockProcedureクラス系を使用します。 これとLegacy_AbstractModuleは同じ概念です。 Legacy_AbstractModuleを理解していないなら、このエントリを読んでください。

モジュールがクラス使用を宣言しない場合では、Legacy_ControlleはアダプターのクラスとしてLegacy_BlockProdecureAdapterを使用します。 このクラスはXOOPS2仕様を完全に模倣します。 Legacy_AbstractModuleとは異なり、Legacy_Controllerは明示宣言なしではブロックのクラスを見つけようとしません。 したがって、モジュール開発者はそれを望むならxoops_version.phpでのブロックのクラス名を定義する必要があります。

How to create instance

1. $modversion['blocks'][x]['class'] = '{Class}'; を xoops_version.php で定義します
2. $modversion['blocks'][x]['file']で指定されたファイルに Legacy_BlockProcedure のサブクラスとして {Dirname}_{Class} クラスを定義します
3. メソッドを実装します

開発者はこれを何のために使いますか？

Legacy_Controllerが正しくアダプターのクラスを使用するので、多くの場合、モジュール開発者はこのメカニズムを使用する必要はありません。 しかし、いくつかのケースでは、XOOPS2 JP仕様は十分ではありません。 それに対して、このメカニズムは役に立ちます。

XoopsBlockへのアクセス

XOOPS2 JPによって呼ばれたブロックショー関数は、この関数のシグニチャがXoopsBlockインスタンスを含んでいないので、XoopsBlockインスタンスにアクセスすることができません。Legacy_Controllerは、Legacy_BlockProcedure::execute() をブロックショー関数の代わりにコールします。したがって、モジュール開発者は$this->_mBlock にアクセスできます。

XoopsBlock解釈の変更

たとえば、piCalはブロックのタイトルを変えるためにcommon.phpが使用した大域変数にアクセスします。 それはすばらしく、かつ、正統でないアプローチです。 しかし、XOOPS Cube Legacyはそのような場合のための正統のアプローチを提供します。 クラスを作成してください、そして、getTitle()をオーバーライドしてください。

ヒドゥンブロック

仮想のcronとしてブロックキャッシュつきブロックを使用するのを望んでいるなら、isDisplay()をオーバーライドしてください。 isDislay()がfalseを戻す場合、Legacyはブロックディスプレイなしでキャッシュを作成しようとします。

描画プロセスの変更

common.phpがブロックを描画するため、XOOPS2 JPブロックはレンダリングプロセスを変えることができません。 しかし、XOOPS Cube Legacyでは、Legacy_BlockProcedureがそれ自身の結果をレンダリングしようとします。 したがって、モジュール開発者はテンプレートファイルや依存レンダーシステムを変更することが出来ます。

Note

もし $modverison['block'][x]['class'] が定義済みであるなら、モジュールインストーラは $modversion['block'][x]['show_func'] を無視します。

実例

βの stdCache モジュールを見てください。

まずはじめに、GIJOEさんのエントリを読んでください。いくつかのXOOPS2が使用するライブラリとモジュールは、 Notice や Warning を発生させます。それらはLegacyの働きに干渉します。 熟慮を重ねた末、私は、再びXoopsErrorHandlerを配置することにしました。しかし、回避策がここにあります。 Legacy_Controllerはデバッガインスタンスを作成するのにデリゲートを使用するようになりました。 したがって、モジュール開発者とユーザはpreloadかmodule preloadでカスタムデバッグモードを使用することができます。 以下のコードは例です。 'preload/DevelopPHPDebugger.class.php'ファイルを作成してください、そして、以下のコードをコピーしてください。

if (!defined('XOOPS_ROOT_PATH')) exit();

require_once XOOPS_ROOT_PATH . "/modules/legacy/class/Legacy_Debugger.class.php";

class DevelopPHPDebugger extends XCube_ActionFilter
{
  function preFilter()
  {
    $this->mController->mSetupDebugger->add("DevelopPHPDebugger::myFactory");
  }

  function myFactory(&$instance, $debug_mode)
  {
    switch($debug_mode) {
      case XOOPS_DEBUG_PHP:
        $instance = new My_PHPDebugger();
        break;

      case XOOPS_DEBUG_MYSQL:
        $instance = new My_MysqlDebugger();
        break;

      case XOOPS_DEBUG_SMARTY:
        $instance = new My_SmartyDebugger();
        break;

      case XOOPS_DEBUG_OFF:
      default:
        $instance = new Legacy_NonDebugger();
        break;
    }
  }
}

class My_PHPDebugger extends Legacy_PHPDebugger
{
  function prepare()
  {
    error_reporting(E_ALL);
  }
}

class My_MysqlDebugger extends Legacy_MysqlDebugger
{
  function prepare()
  {
  }
}

class My_SmartyDebugger extends Legacy_SmartyDebugger
{
  function prepare()
  {
  }
}

Description

サブコア Legacy は、仮想コントローラを持っています。このコントローラは、新しいインタフェースを通じて、モジュール、ブロック、及び、テーマを扱います。

(XOOPS Cube における「コントローラ」は CMS の手続きとしての一種の枠組であって、開発フレームワークではありません )

XOOPS2 case

まず初めに、 XOOPS2 の仕様を思い出してください。XOOPS2 には XoopsModule 、及び、 XoopsBlock があります。これらのクラスは、モジュールデータ & ブロックデータを扱うための基底クラスです。 XOOPS2 は、それらを直接扱います。従って、モジュール開発者は、 XOOPS2 が xoops_version のデータをどのように解釈するかということに、従わなければなりません。例えば、モジュールは、いかなる影響も XOOPS2 のキャッシュ機能に与え得ず、また、ブロックのタイトルを変更することもできません。

Legacy case

さて、 Legacy の代替アーキテクチャを見ていきましょう。Legacy controller は、 XoopsModule 、及び、 XoopsBlock を直接使いません。Legacy は、データ解釈を Legacy_AbstractModule 、及び、 Legacy_AbstractBlockProcedure に委託します。これらのクラスは、コントローラと接続するためのインタフェースを持つ抽象クラスです。モジュール開発者は、コントローラから使用されるように、これらのクラスのサブクラスを定義し得ます。サブクラスには、そのメンバープロパティとして XoopsModule オブジェクトがあります。従って、モジュール開発者は、彼のモジュールサブクラスにおいてデータ解釈を変えることが可能です。

How to create an instance

1. 'Module.class.php' ファイルをモジュールの /class ディレクトリ下に作成してください
2. {Dirname}_Module クラスを Legacy_AbstractModule のサブクラスとして定義してください
3. メソッドを実装してください

{Dirname}_Module がすでに定義されている場合は、インスタンスファクトリは 'Module.class.php' をロードしません。このルールは複製可モジュールに有効かも知れません。ぜひレビューしてください。

詳細は /module/legacy/class/Module.class.php を例としてご覧ください。また、実装すべき 'オーバーライド可能' なメンバ関数については、 Legacy_AbstractModule をご覧ください。

For compatibility

大部分のモジュールは、そのようなサブクラスを持っていません。モジュールがそのようなサブクラスを持っていない場合、 Legacy は、 'Legacy_ModuleAdapter' を XOOPS2 互換性のためのアダプタクラスとして使います。このアダプタは、完全に XOOPS2 仕様を模倣します。更に、このアダプタクラスは抽象クラスではありませんので、迅速な使用に有益です。モジュール開発者は、このアダプタクラスをサブクラスのための基底クラスに選ぶかもしれません。

Is it possible to change factory?

ファクトリの前提条件は、 $xoopsModule->get('dirname') によって指定されたモジュールが、モジュールの /class ディレクトリに Module.class.php を持っていることです。この仕様は、複写可能なモジュールにとっては、には不幸です。サブクラス、及び、アダプタクラスのインスタンスを生成するためのファクトリは、 Legacy_Utils に静的関数としてあります。そのため、モジュール開発者は、命名規則を変更出来ません。言い換えれば、そのファクトリは固定パイプライン機能です。しかし、ファクトリの関数は、 XCube_Delegate を使います。従って、開発者は、デリゲートを通じて固定パイプラインのファクトリに割り込むことができます。

同様に、既に指定されたクラスが定義されているならば、 Legacy が Module.class.php の読み込みをスキップすることは、重要です。従って、複製可能なモジュールへの多くの解決策が発案されるでしょう。ぜひレビューをお願いします。

Note

Legacy が作成するインスタンスは、 $root->mContext->mModule にセットされます。ルートオブジェクトを得ることによって、モジュール内でこのインスタンスにアクセスすることができます。

Reviews

"基底クラスは Legacy モジュールの /kernel ディレクトリにある。したがって、ファクトリもまたファイルを /kernel ディレクトリに求めるべきである。" (minahito)

You must do some processes before Beta installation.

Uninstall the base module and the user module

At first, turn off the active value of these modules in the module management:





Then, you'll be forward to the 2nd installer. Uninstall two modules completely. Don't forget clicking 'Uninstall'.

Remove the base module form your file system

You must use the legacy module instead of the base module. Therefore, you don't need the base module. If you keep the base module, Beta may get some troubles. You must remove it. OK?

Overwrite files with the beta

Then, you will see the following screen after upgrade. Click 'Install' button to work the beta.

主要なクラス、重要なプロパティとメソッドがこのダイアログに載っています。このダイアログはすべての要素を含んでいるというわけではありません。しかし、それは Beta を読むには十分です。

ＰＤＦファイルはここにあります。印刷して、トイレの壁に貼ってください:

XOOPS Cubeは小さい政府主義を志向し、小型のコアプログラムとコンベンションを開発します。 XOOPS JPはマルチバイトとセキュリティ方針に関して XOOPS2 と異見があります。これらの問題により、私たちはフォークしました。 だれでもCubeの世界では公式のマークなしで解決策を開発することが出来るので、Cubeには同様の問題はありません。

しかし、何人かのユーザは、Cubeは新しい公式サイトを得るためにフォークしたのだと考えています。 彼らは、セントラルチームが何であるかを見いだすことができていないので、Cubeの方針に混乱しています。 私たちの方針はまだ（厳格に）統一されてはいません。しかし、私たちはXOOPS2の中央集権制とは異なったスタイルを目的としています。これは確実なことです。無政府主義は活発な人々の情熱を妨げません……なぜなら、だれも認可を得る必要がないからです。チームメンバーの数には上限がありますので、オープンな公式のチームは実現困難です。 しかし、公式という概念が存在しないなら、開発者は、いつでも自由に加わって、抜けることができます。 私たちはCubeに関するどんなプロジェクトにも干渉するようなキャプテンを必要としていません。

オフィシャルと3rdの違いを取り除く

公式サイトが中央であることは良い考えではありません。Cube には、交換可能なベースモジュールと十二分な柔軟性があります。 しかし、サイトには、1つの特定の実現がなければなりません。 それはCubeの真価の否定です。 そして、私は、他のリポジトリにおける行動派の人々が '3rd party' と呼称されることを理解することができません。 それはナンセンスです!

いかなるプロジェクトのいかなる開発者も他のプロジェクトにいかなる特権を持ちません。

行動派はお気に入りのプロジェクトを選択する

例えば、現在、私は Cube 開発チームのコアメンバーのひとりです。

しかし、私は、XUGJの通常メンバーでありたいです。もちろん、私が、XUGJで一生懸命活動するのを望んでいるなら、XUGJは私を受け入れるでしょう。

xoopscube.jp は私たちではなく行動派の方々によって管理されるでしょう。

管理者は、彼らのデフォルトのための1つのベースモジュールを選んで、xoopscube.jpパッケージを計画します。 私はその計画に干渉しません。 そして、私には、そのプランに関して一切の義務がありません。 しかし、それがおもしろいなら、私は、開発者としてプランに参加することを望むかもしれません。 この場合、私はコアメンバーではなく、ゲスト開発者です。

開発者は自分の自由時間に合わせてどのプロジェクトに参加するか決定する

開発者は自分の自由時間がどれくらい長いかによって、バイキング料理を楽しみます。


「うーん、一日あたり３時間の自由時間か……」
「どのプロジェクトを選ぼうか？」

メンバー交替

私は来年、開発チームを離れるつもりです。 それはCubeスタイルのための一種のテストです。 このスケジュールは昨年に決められました。 しかし、コアメンバーには多すぎる義務がないので、次世代開発者を見つけるのは簡単でしょう。彼が .jp か .org に参加することを望んでいるなら、彼は、それらにメンバーであることを要求するかもしれません。 彼が望むなら、より多くのプロジェクトを選べばよいでしょう。 私はCubeツール開発があるXOOPS Cubeを継続するつもりです。そして、必要に応じて、私は、再びメンバーであることを要求するかもしれません。

私たちはPHP4でインタフェースと多重継承を使用することができません。そのため、いくつかの XCube 層のクラスを設計することが困難になっています。 例えば、XCube_PageNavigatorは、情報の交換のために他のインスタンスに接続する必要があります。しかし、他のクラスは他の基底クラスを拡張するかもしれません。したがって、XCube_PageNavigatorによってコールされるメソッドを持っている抽象クラス（インターフェイス）を定義したいと考えます。しかしながら、それはPHP4では不可能です。ですから、私は XCube_Delegate を使用しなければなりません。

といっても、PHP4 は型安全ではありませんから、私は開発者のためにインターフェイス定義を示すためにダミーのクラスを定義することができます。ひょっとすると、PHPの偉大なプログラマはそのようなコードをスマートに書いているのかもしれない。しかし、私はPHPとライトウェイトのプログラミングに関する Tip を知りません。私の経験は型安全な言語のみです。そのため、XOOPS CubeのソースコードはPHPプログラマに対して決して美しくありません……

私は私たちが使用するプログラム言語が何であるかにこだわりません。 PHP4がレンタルサーバの主要な環境であるなら、私たちはXOOPSにPHP4を使用するべきです。 これはエンタープライズではありません、ただ趣味です。しかし、PHP4のいくつかの仕様がXOOPS Cubeコードを不透明にします。

私は頭が固いのです。そして、私は、ライトウェイト言語を使いこなせていません。私は、さらに学ぶ必要があります。

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 は、そのキャッシュメカニズムを働かせることができません。

XOOPS Cube Legacy2.1アルファー5は現在、利用可能です。 アルファー5は多くのバグフィックスと私がアルファー4まで開発するのを忘れた新しい移植された特徴を含めます。 それらの特徴はXoopsFormテンプレート、はるかに良いキャッシュメカニズム、およびフルスペックの(?)ユーザ検索です。 これらの新しい移植された特徴は重要ですが、多くのフィックスが、より重要です。 これらのフィックスは多くのテスターによって報告されました。 私の友人に感謝します!

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

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

XOOPS Cube がフォークして以来、私は英語を勉強し始めなければならなくなりました。私の英語は非常に貧しいのですが、しかしそれは私のためのXOOPS Cubeの最大の収穫です。しかし、日本語の私のブログがただ機械翻訳であるので、日本版の私のブログはだめな品質になりました。

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としてこれらの機能を交換するつもりです。 そして、標準のキャッシュモジュールはデフォルト機能を代表に提供するべきです。

既存のキャッシュファイルをきれいにする手段も重要です。

私は、この数週間予想外に忙しく過ごしていました。家に帰らずに、仕事を続けていました。プロジェクト・チームの私の仲間もまた、私と同様に忙しいです。そのため、プロジェクト・チームは、またしても、スケジュールの遅れを公表しなければならなくなりました。しかし、よいニュースもあります。それは、多くの熱いユーザーが、これらの数週間の間、チェックとレビューを試みたので、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 をテストしましょう。

私は、 Alpha4-c でへまをやらかしました ...

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

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

マイクロソフトはちょうどXNA Game Studio Express Betaダウンロードをリリースしたところです。 私は、このベータをテストするために加わるつもりです。 しかし、私はXOOPS Cube Legacy2.1.0のBetaを最優先させなければなりません。Umm…

9月に忙しくなり過ぎるので、私はLegacyのほとんどのタスクを今月終えたかったです。 恐らく、私はうまくいった状態でそれらを終えました。 Legacy には、多くの短所があります。 しかし、これらの短所は、プロジェクトチームがリリースを遅らせる原因にはならないでしょう。私たちは2.1.0の後で「クールでない」問題を修理すればいい。

私は今月、かなり楽しかった。 XOOPS Cube Legacy2.1.0のテストはまだ十分ではありません。 しかし、多くのテスターがアルファーを見直そうとするので、私は心配していません。テストにジョインしてください。以下はレポート場所のリストです。

• http://xoopscube.org/ (これは今最高のサイトです。多くの熱血漢がいます！)
  
• http://xoopscube.jp/ (日本語オンリーです)
  
• htp://xugj.org/ (2.1報告フォーラムが開かれました)
  
• http://www.xc-tokai.com/ (このサイトの管理者は Tom_G3X 氏です)

さらに、あなたはバグをあなたの国のサポートサイトに報告することができます。 あなたの国のサポートサイトの管理者はあなたのレポートをプロジェクト・チームに伝えるでしょう。

よろしくお願いします。

XOOPS2の歴史の中で、多くのデザイナーが、テーブルタグベースのXOOPS2テンプレートに異議を唱えました。そこで、私は、Shadeを valid HTMLテンプレートにしてみようと思い立ちました。しかし、エンドユーザにとって扱いやすいので、テーブルタグベーステンプレートも有益です。

おそらく、最も良い解決策はXLST+XMLテンプレートです。 この解決策で、私たちは valid HTMLテンプレートと非 valid HTMLテンプレートの両方を扱うことができます。 しかし、私は重要なことを忘れていました。だれがそのような難しいシステムを扱うことができるか？という問題です。それがXLST+XMLではなく、ただの valid HTML テンプレートであったとしても、エンドユーザにとっては十分難しいです。

プロのデザイナーにとって、 valid HTML テンプレートは朗報です。彼らは自由自在にHTMLとCSSを調整することができます。もちろん、彼らはXLST+XMLもよく知っています。 しかし、私のようなウェブ世界のエンドユーザは、そのような技術的なものは決して制御することができません。

この例を見てください。 多くのデザイナーが以下のような HTML を嫌っています。

<font color="red">{$date}</font><br/> / {$poster.name}

それは確かにun-validです。 しかし、エンドユーザはテンプレートマネージャで色を変えることができます。 (彼のテーマの背景色が赤ならば、フォントカラーを変えざるをえないでしょう)

テンプレートが valid HTML であるなら? 彼はCSSを変えなければならないでしょう。そのため、動的CSSメカニズムとCSSマネージャが必須スペックになります。そして、もし項目の位置を変えたいなら、CSSの知識を使ってテンプレートとCSSの両方を変えなければなりません。それはエンドユーザにとってまず無理な話です。

valid HTMLテンプレートのために、私たちは「エンドユーザはHTMLとCSSを変更することができない」という前提条件に立たなければなりません（XOOPSはホビー玩具ですからね）。そして、原則として、テーマがモジュールのテンプレートとCSSの両方を持つことになるでしょう。 RapidWeaver は、そのようなシステムになっています。そして、プロフェッショナルなデザイナーのコントリビュートが必須になるでしょう。

私はXOOPS Cube層のXCube_Serviceを開発しなければなりません! そして、そのクラスはプロジェクト・チームの他のメンバーによってレビューされなければなりません。 それに関しては、私は日陰研究所を作りました。 すみません! それは日本語専用です。

XOOPS Cube層には、2つの未フィックスな特徴があります。 それらは、XCube_UserAccountとXCube_Serviceです。 私はそれらに関して良い案があります。 XOOPS Cubeは接続する抽象的なインタフェースです。 したがって、XCube_UserAccountはウェブブラウズのアクセサとウェブサービスアクセサのための抽象的な層です。 そして、XCube_ServiceはXOOPS Cubeの就航メカニズムです。

私はXOOPS Cube Shadeでそのようなデザインを確立しなければなりません。

私たちは Cube Legacy 2.1.0までに XOOPS Cube のマニフェストのフォーマットをフィックスすることができないかもしれません。それはまだ必須の仕様ではありませんので、私はプロトタイプツールを開発することを試したいと思います。

XOOPS Cube のマニフェストは、アップデート情報、重要なニュース、他のモジュールへの依存、および規則スタイルを示す基礎データです。 XOOPS Cubeプロジェクト・チームはフォーマットのみを決定します。そして、他のプロジェクトはマニフェストを取り扱うことでユーザを助けるツールを開発しようとします。 そのようなツールが、Windows OS アプリケーションと Mac OS X アプリケーションであることがベストです。それが XOOPS Cube プロジェクト・チームが直接そのようなツールを開発しない理由です。

そのようなツールは常にC++プログラマを必要とします。XOOPS Cubeプロジェクトにそれを絶えず要求するのはお門違いでしょう。PHPプログラマとC++プログラマは異なった得意分野を持っています。私は、XOOPS Shade Projectでそれを開発することを計画しています。

ツールには、以下の仕様がなければなりません:

• ツールはFTP、SFTP、およびSCPで直接XOOPS Cubeサイトに接続しなければなりません。
• ツールはマニフェストによってファイルのアップロードとダウンロードが可能な、一種のネットワーククライアントでなければならない。
• ツールはXOOPS Cube Legacy、D3モジュール、およびXOOPS Cube Shadeをカバーしなければなりません。それらの構造が異なっているとしても。
• もちろん、ツールはテーマを扱うことができなければなりません。
• ユーザがモジュールをインストールしようとするとき、ツールはモジュールの依存モジュールを管理しなければなりません。
• モジュール開発者は、彼らのモジュールを発行するために、特別なメカニズムを持つ必要はありません。

これらの仕様を持つツールはXOOPS Cube世界への必須品です。 私たちはおもちゃとしてXOOPS Cubeを開発しようとしています。しかし、XOOPS Cubeはおもちゃではなく、ただPHPプログラムです。 したがって、私たちはCubeをおもちゃにするツールを開発しなければなりません。私たちが .NET Framework や Mac OS X の WebKit を使用することができるので、そのようなツールを開発することは困難ではありません。これらの環境はネットワーククライアントアプリケーションを開発することを容易にします。

しかし、私はリナックスデスクトップアプリケーション開発に関して詳しくありません。それは問題です……しかし、サイトオーナーは windows か Mac OS X のどちらかは持っているでしょう。

遅くなりました。これらの PDF ファイルは先月 XTC2006 において、私が使用したものです。これらのファイルが日本語オンリーであることを申し訳なく思います。

• XOOPS Cube 2.1 コンセプト紹介＆開発状況
  
• モジュール開発環境 Cubson GUI Force 紹介

XOOPS Cube はもうすぐやってきます。これらのファイルは Cube のスピリットを理解するために役立ちます。

.NET を知っていますか ?　.NET は、マイクロソフトによって開発された開発された windows OS 上のフレームワークです。デスクトップアプリケーション開発は、ウェブアプリケーション開発より容易です。.NET は、デスクトップアプリケーションと同じくらい簡単に、ウェブアプリケーションを開発することのを可能にします。.NET における開発は、マウスドラッグ、及び、少しのコーディングから成っています。マウスドラッグによって、私達は、様々な独立したコンポーネントを我々のアプリケーションに入れます。それから、デリゲートなどを用いて、各コンポーネントを接続するために、プログラムを組みます。

しかし、 .NET のこれらの特徴は、開発者のために作られています。エンドユーザー（アプリケーションを発注する顧客）はこの開発方法とほとんど関係がありません。私は、 XOOPS におけるユーザーはコンポーネントとしてモジュールをインストールし、各モジュールを接続するためのなんらかのメカニズムとしてデリゲートを使用するようになると思います。これは、 .NET プログラマの仕事の一部に、エンドユーザーが楽しみを見いだすであろうことを意味しています。

Legacy は XOOPS2 ベースですので、私達は、 Legasy 上でこの理想を達成することができません。しかし、モジュールはコンポーネントの一種であり、 1 File Hacking は（.NET プログラマがするように）デリゲートでそれらを接続するプロセスです。言い換えれば、 .NET のコンポーネント、及び、 .NET のデリゲートは、開発者のためのものですが、 Cube のモジュール、及び、 Cube のデリゲートは、ユーザーのためにあるということです。

私は、開発者が更に小さいコンポーネントをドロップすることで、 Cube コンポーネントとしてのモジュールを完成させることができる RAD ツールを開発することを望みました。しかし、私には、それをするための時間が十分ではないかもしれません。

趣味 CMS として完成されるために、 XOOPS Cube は、開発者が .NET で使用するこれらのメカニズムを導入しました。しかし、エンドユーザーは、高みに上がることを強制されることになるでしょう。一部のユーザーは、 Cube を拒絶するかもしれません。それゆえに、フォークは、良い選択です。なぜなら、彼らは、 XOOPS に戻ることができるからです。私達は、フォークによってほんの 1 つの新しい選択肢を得ました。 xoops.org のユーザーも Cube を見れば、私達のフォークの意味に納得するでしょう。

少なくとも日本において、ユーザーが動的なサーバアプリケーションに作ることを楽しむという趣味がありません。もちろん、ユーザーは、 XOOPS のように CMS によってそれらのホームページを作成することは楽しみます。しかし、だれも、 CMS の組み立てをレゴブロックのような楽しい趣味と見なしません。XOOPS Cube は、それに挑戦しています。従って、現在のユーザーは、壁にぶつかることになるでしょう。 Cube は新しいコンセプトを彼らに強要します。彼らは、新しい世界の先駆者として、その壁を粉砕しなければなりません。

ユーザはXOOPS Cubeのためにプロジェクト・チームより熱心です！　彼らは9月3日に私たちのBetaを完成させてしまうでしょう。 私は、もうひとつのベースモジュールを仕上げることを急がなくてはいけません。それはXOOPS Cube層の設計思想を証明する実験的なアプローチです。 私は、私の実験用アプリケーションを XOOPS Shade と命名し続けています。

最初のXOOPS ShadeはXOOPS Cube層に変わりました。もともと、私は XOOPS Cube の原型としてそれを開発していました。もちろん、プロジェクトチームのメンバーがレビューしましたので、現在XOOPS Cube層はXOOPS Shadeと比べものになりません。

第2のXOOPS Shadeはベースモジュールの１種として開発されました。 プロジェクト・チームは、XOOPS Cube 層がXOOPS2の一切のコードを必要としないことを証明するために、もうひとつのベースモジュールを必要としました。しかし、第2のXOOPS Shadeがどうにもおもしろくないので、私はそれを開発することをストップしました。

３番目のXOOPS Shadeもベースモジュールの種類として開発されます。XOOPS Cube Legacyが来月には完成することを考えれば、これはXOOPS Cubeのための重要な計画となります。 言い換えれば、私たちは９月中にXOOPS Cube層の仕様を確立しなければなりません。３番目のXOOPS Shadeは最後の挑戦です。

このページを参照してください。 このページはXOOPS Cube Shadeのサンプルページです。 あなたは、XOOPS Cube ShadeがXOOPS Cube Legacyと違うものだということを理解するでしょう。しかし、XOOPS Cube ShadeはCubeファミリーの一員なのです。

恐らく、ユーザは自身のベースモジュールとしてLegacyかLegacyのサブクラスを使用するでしょう。 LegasyにはXOOPS2のすばらしい歴史があるからです。しかし、実験は常に重要なのです。 XOOPS Cube Shadeには、明白な'存在理由'があります。

Practice

恐らく、あなたは、 Preload を使いこなすために XOOPS Cube Legacy のその他のメカニズムを理解する必要があるでしょう。プリロードは、ほとんどのカスタマイズの起点となります。

しかし、今は Preload を理解することが、重要です。そこで、 Preload のみを使用して実例を作成しましょう。それは、 ForceSiteClose というものです。 ForceSiteClose は、特定の IP を除いて全ユーザーのために全ユーザーに対してサイトクローズを行います。それは、テストに便利です、なぜならテスターは特定のIPから来ていれば、ゲストユーザーとしてサイトにアクセスが出来るからです。ForceSiteClose によって、サイトオーナーは、テストしながら訪問者に対してサイトを閉じることができるのです。

class ForceSiteClose extends XCube_ActionFilter
{
  var $mSpecificIPs = array('127.0.0.1');

  function preFilter()
  {
     $ip = $_SERVER['REMOTE_IP'];
     if (!in_array($ip, $this->mSpecificmIPs)) {
         $this->doSiteClose();
         exit();
     }
  }

  function doSiteClose()
  {
     //
     // You must rewrite the following for your expression.
     //
     print "This site is closed now, Because ...";
  }
}

あなたは、データベース障害に際してこのフィルタを使ってもよいでしょう。なぜなら、 ForceSiteClose は、データベースなしで動くからです。一方、 XOOPS Cube Legacy のサイトクローズは、データベース障害の下では動きません。

Future XCube_ActionFilter

これは、 ActionFilter に詳しい開発者のための備考です。

Legacy_Controller において、 ActionFilter 機能は、サイトプリロード、及び、モジュールプリロード専用です。つまり、それは、サイト所有者とモジュール開発者がカスタマイズを行うために存在します。Legacy_Controller は、自身を構築するために ActionFilter 機能を使いません。従って、いくつかのフレームワークの ActionFilter と Legacy_Controller における ActionFilter は異なっています。

onokazu 氏は Legacy_Controller がそれ自身を構築するために ActionFilter を使うことは、スマートなプログラムであると言いました。彼のアイデアは、まったく正しく、かつ魅力的です。 ActionFilter はシンプルなメカニズムにすぎませんから、 XCube_ActionFilter のクラス設計は、その用途に十分です。

最終的に、私達は、実例による役割分担の明確化のために Legacy_Controller のこの設計を保持することにしました。ベースモジュールでコントローラを作るためにあなたがそれを使うことは、自由です。そして、近い将来リリースされるであろういくらかのベースモジュールは、そのような目的のために ActionFilter を使うかもしれません。

我々が少なくともそのような使用を検討したことを留意してください。

How to define ActionFilter

XCube_ActionFilterの2つのメンバ関数は仮想関数です。 したがって、あなたは、XCube_ActionFilter のサブクラスを定義して、目的にあわせてオーバーライドでこれらのメンバ関数をオーバーライドを用いて実装しなければなりません。

しかし、Legacy_Controller があなたの ActionFilter を積み込んで、それをセットアップしないなら、あなたの ActionFilter のための定義はがらくた同然です。あなたは Preload フィーチャーを、あなたのファイルをロードしてクラスをセットするメカニズムとして利用する必要があります。

Legacy_Controller は規則的にあなたの XCube_ActionFilter のサブクラスのインスタンスを作成します。 Site PreloadとModule Preload はお互いに異なる規則を持っています。まずはじめに、Site Preloadの規則を学んでください。

1. /preload ディレクトリに {filename}.class.php となるファイルを作成する
2. {filename} クラスを XCube_ActionFilter のサブクラスとして定義する

preBlockFilter()でプロセスを止めるサンプルフィルタを作成してみましょう。 初めに、/preload で 'KillBill.class.php' を作成してください。 次に、'KillBill' クラスを以下のように定義してください。

class KillBill extends XCube_ActionFilter
{
  function preBlockFilter()
  {
    die("Kill Bill!");
  }
}

それにより、あなたは、あなたを'KillBill'メッセージによって、あなたの稼働中のXOOPS Cubeにアクセスできなくなります。このルールがどれほど重要であるかを知るために、クラス名を変えてみましょう。

class KissBall extends XCube_ActionFilter

それから、あなたはあなたの稼働中のXOOPS Cubeにアクセスすることができるようになります。 何もあなたを妨げません。Legacy_Controller はこのファイルをロードして、このクラスを定義しますが、彼は、それが違反するので、それをチェーンに積みません。あなたは、あなたのクラスライブラリをロードするのにPreloadのこの特性を使用することができます。

このエントリでは、 XCube_ActionFilter について学びましょう。ActionFilter は、 mojavi2 から拝借されたアイデアです。あなたが mojavi2 ではなく、 C もしくはアセンブリを知っているならば、ファンクションポインタを配列にプッシュし、後からこれらを順番に呼び出していくテクニックを覚えているかも知れません。ActionFilter は、そのテクニックに似ています。Legacy_Controller は、 XCube_ActionFilter の様々なサブクラスのインスタンスを作成し、そして、これらのインスタンスを、コントローラのメンバプロパティである mFilterChain にプッシュします。

では、 XCube_ActionFilter のクラス設計を見てみましょう。この設計が XOOPS Cube の正規バージョンまでに少し変更されるかもしれないことを覚えておいてください。

XCube_ActionFilter は、 preFilter() と preBlockFilter() という 2 つのメンバ関数を持っています。これらの 2 つのメンバーファンクションは、 Legacy_Controller によって特定のタイミングで呼ばれることになっています。 preFilter() は、 Legacy_Controller の executeCommon() の最初の部分で呼ばれます。それが、 XOOPS2 の common.php と似ているので、私は executeCommon() を「コモンプロセス」と呼んでいます。

preFilter() の中では、データベースインスタンスを使うことができません。なぜなら、このメンバ関数はコモンプロセスのまさに最初の部分だからです。そう、このメンバ関数は、 Legacy_Controller がデータベースクラスのインスタンスの作成を試みる前に呼ばれます。

preFilter() は、何のために使われますか ?　あなたは、あなたのロジックをコモンプロセスの最初の部分に挿入するために、それを使うことができます。preFilter() の時点で Legacy_Controller が自身のセットアップをほとんど終えていないので、 preFilter() の用途は制限的かもしれません。あなたは、 preBlockFilter() の中で XOOPS Cube のリソースにアクセスするために多くのインスタンスを使うことができますが、 preFilter() の中ではそれはできません。

従って、あなたは、 XoopsProtector のような mainfile.php ハックの代わりに preFilter() を使うのがよいでしょう。言い換えれば、あなたは、それが preBlockFilter() のタイミングで呼ばれるには遅すぎるロジックのために preFilter() を使えばよいのです。

Legacy_Controller がブロックの準備を始める直前に、 preBlockFilter() は、呼ばれます。 preBlockFilter() は便利です。なぜなら、あなたはこのメンバ関数の中では多くの関数および多くのインスタンスを使うことができるからです。例として、データベースインスタンス、または、 XoopsObject ハンドラによってデータベースにアクセスすることが容易です。恐らく、 preBlockFilter() は、ほとんどのケースで使われるでしょう。

私たち日本人は今お盆です。お盆は、仏教の儀式であり、日本における一種の夏休みです。私も5日間の休みを確保したので、 Eclipse と sourceforge 用の SSH キーファイルをインストールした mac mini と一緒に広島に戻りました。この mac を使って、私はコミットとチェックアウトが可能です。この mac mini のおかげで、私は実家でもコミットとチェックアウトが可能です。

MacのLAMP環境とWindowsの私の普段のLAMP環境は異なっています。 その違いが私が知っていないいくつかのエラーの引き金となるので、私はそれらのバグを修理することができます。 同様に、私はloglogのいくつかのバグを修理しました。 あなたはloglog 0.21をここでダウンロードすることができます。

そして、私はSQL用のシンプルな字句解析を開発しました。(それは、Roadmapに示された目標の1つです)。 次に、私はメッセージカタログを調整するつもりです。 これらのタスクを終えれば、私が帰京する頃には、Alpha4-cをリリースすることができるでしょう。

xoopscube.orgフォーラムの私の友人たちは私が忙しい休暇を過ごすのではないかと心配してくれました。ありがとうございます。 しかし、心配しないでください。 開発は私の趣味であり、そして、多くのバグレポートが私を支えてくれます。私は、バグフィックスを楽しんでます。また、明日には広島市民球場で私の旧友と野球の試合を見に行くつもりです。これはたいへん充実した時間といえるでしょう。

私は十分に夏休みを楽しんでいます。もしよければ……そしてあなたが休暇中なら、あなたも XOOPS Cube の新機能を試用することを楽しんでください。

Loglog は、難しいサンプルであったかもしれません。XOOPS Cube における重要なフィーチャーは、プリ‐ロード、デリゲート、及び、 Xube_Service です。あなたは、これらのフィーチャーによってさまざまにサイトをカスタマイズすることができます。最初は、 Preload を学んでください。

2 種類の Preload （ Site Preload と Module Preload ）があります。Site Preload は、本当にシンプルですです。

1. /preload ディレクトリに XXXX.class.php を作成してください
2. XCube_ActionFilter のサブクラスである XXXX クラスを定義してください
3. 目的に合わせて preFilter() と preBlockFilter を実装してください。これらのメンバ関数は XCube_ActionFilter の仮想関数です。

XCube_ActionFilter のメンバ関数は、コモンプロセス（XOOPS2 の common.php と同様に、初期化プロセスを実行する）において呼び出されます。
XOOPS2 では、サイトオーナーが初期化プロセスにおいて彼らのコードを実行する方法が全くありませんでした。それをするために、彼らは、 XOOPS2 コアのソースコードを修正（=hack）しなければなりません。

プリ‐ロード、及び、 ActionFilter は、その問題へのソリューションです。これらのフィーチャーによって、サイトオーナーは、ハックなしで初期化プロセスにおける彼らのコードを実行し得ます。そして彼らはそれを。

あなたはプリロードファイルが新たなパブリケーション単位であることを理解します。サイトオーナーはそれを彼らの友人と共有するかもしれません。そして、彼らはそれをモジュールやテーマと同様にリリースすることが可能です。

Preload は多目的に使えます。

• カスタマイズのための初期化コードの実行
  • 自分の関数を他のモジュールのデリゲートに追加
  • サービスやデリゲート関数を定義し、他のモジュールのためにそれをコアに追加
  • コアのオブジェクトの交換
• 必須ライブラリのロード

あなたは Cube をテストすることを楽しむ 'loglog' モジュールをここからダウンロードできます。これは、「対数の対数」に関する数学モジュールではありません。

Loglog は、 XOOPS Cube 層の Delegate を使うサンプルプログラムです。 Loglog は、いつユーザーがログイン、または、ログアウトをするかを記録し、そして、ユーザーがサイトにどのくらい滞在しているかを推測します。

preload/Initialize.class.php を読んでください。英語、及び、日本語でコメントがあります。XOOPS Cube のデリゲートは、コールバックに関する統一手続きです。それは、 C のファンクションポインタ、 C++ の ファンクタ 、 C# と D のデリゲートのようです。あなたがサンプルを読むことで、 Delegate のエッセンスを理解できます。

Loglog は、単なるサンプルプログラムです。しかし、あなたが更に本格的なロギングモジュールを望むならば、ぜひそれを作ってください！　ユーザー全員が、あなたの行動を歓迎します。

我々、プロジェクトチームは、 Alpha4 をちょうどリリースしました !　私は、非常に興奮しています。なぜなら、それは、 XOOPS Cube Legacy 2.1 におけるファイナルラウンドの始まりだからだ。ユーザーは、多くのバグを報告するでしょう。我々は、それらのバグをフィックスし、そして、いつでもパッケージを再アーカイブするでしょう。重要なバグが取り除かれるであろうとき、 XOOPS Cube Legacy 2.1 は、 Beta になるでしょう。言い換えれば、 Beta は、全てのユーザー（我々を含みます）によって完成されます。

Alpha4 をあなたのローカルな機械にインストールして、そして、あらゆる問題を報告してください !　もちろん、我々は、あなたがそれをあなたの公開サーバにインストールすることを試みるあなたの勇気を歓迎します。私は、 Alpha を私のサイトに既にインストールしました。

あなたのレポートは、βまで XOOPS Cube αを前進させます。我々は、迅速にあなたのレポートをチェックするでしょう。ファイナルラウンドのゴングは、打たれました !

私はこのブログを昨晩アップデートできませんでした。さて、いよいよ私達はDoxygen によってXOOPS Cube のソースコードからドキュメントを生成します。

Doxygen は Doxywizard という名前の GUI アプリケーションを備えています:

それはDoxygen のためのコンフィギュレーション・ファイルを生成し、そのコンフィギュレーション・ファイルによってDoxygen を実行します。さらに、Doxywizard にはウィザードとエキスパートという、初級者と上級者のための、２つのセッティング方法があります。PHP プログラムはほとんど高度な設定を必要としないので、ウィザードモードの使用法だけを覚えればよいでしょう。


Doxywizard を実行し、それから、 Wizard ボタンを押します。


あなたがダウンロードした XOOPS Cube のディレクトリを 'Source code directory' にセットしなさい。そして、サブディレクトリを解析するために、 'Scan recursively' オプションをチェックしてください。それからドキュメントを収納するディレクトリを作成し、それを 'Destination directory' にセットしてください。 'Project name' と 'Project version or ID' は自由です。


次に、 Mode タブをクリックしてください。


'All entities' を選択してください。それにより、すべてのエンティティが、それがドキュメントシステムのためのコメントを持っているかどうかに関係なく、ドキュメントのために解析されます。それから、 OK ボタンを押してダイアログを閉じてください。


次に、このセッティングをファイルに保存しなければなりません。Doxywizard は Doxygen を実行させるためにコンフィグレーションファイルを必要とするためです。Doxywizard はあなたが保存したファイルを Doxygen のためのコンフィグレーションファイルとして用います。


次に、 Doxygen がドキュメントを生成するためのテンポラリファイルを作成するディレクトリを指定しなければなりません。あなたの OS のテンポラリ・ディレクトリか、新しいディレクトリを作ってそれを指定するとよいでしょう。

あなたはこれでドキュメント生成のための最低限のセッティングを終えました。最後に、 'Start' ボタンをクリックしてください。ドキュメントがあなたが指定した転送先ディレクトリに生成されるでしょう。

あなたは再度これらのセッティングを行う必要はありません。いつでもコンフィグレーションファイルをロードし、ドキュメントを生成できます。

XOOPS は、 PHPDoc をドキュメントシステムとして使います。Doxygen と、 PHPDoc の両方は、 javadoc のドキュメントタグを扱うことができます。しかし、各ドキュメントシステムは、いくらかのオリジナルの規則を持っています。そして、 Doxygen が C/C++ のために開発されてきたので、 Doxygen は、 PHP プログラムのために上手にドキュメントを生成できないかもしれません。

しかしながら、 Doxygen は、 PHPDoc よりあなたのために使い易いでしょう。私は、 Doxygen によって生成されたドキュメントが好きです。XOOPS Cube において、我々は、 Doxygen のオリジナルのタグを利用するべきでありません。従って、生成されたドキュメントは、 Doxygen の最大効果を含みません。しかし、それは、十分です。

試してみましょう。まずはじめに、 CVS から最新版をチェックアウトしてください。それをするために、あなたは、 XOOPS Cube Gems でこの記事を参照できます。次に、 Doxygen をダウンロードして、そして、それをインストールしてください。

次のエントリで、あなたは、これらのソフトウェアによってドキュメントを生成するでしょう。また明日お会い致しましょう。

XOOPS Cube が多くのファイルと多くのクラスを持つため、 XOOPS Cube のソースコードを読むことは難しい。Cube のソースコードを読むために、私は Doxygen を推奨します。 Doxygen は有名なドキュメントシステムであり、ソースコードを解析して HTML ドキュメントを生成します。そうです、それは javadoc の一種です。Doxygen がクラス名とファイル名でドキュメントをサーフィンするためにハイパーリンクを作成するので、生成されたドキュメントは本当に有益です。あなたはネットサーフィンをするように「ドキュメントサーフィン」をすることができます。

ソースコードをあなたのドキュメントに出力するために、ソースコードオプションを有効にすると良いでしょう。生成されたソースコードページは、クラス名と定数のところで、同様にリンクを含んでいます。これらのページはIDEを使うより良い。あなたは必要なクラスと定数を容易に調査し得ます。

恐らくあなたはソースコードを読むのに IDE を使うことをやめるでしょう（その IDE が VisualStudio だとしても）。

ドキュメントシステムのためにすべてのクラスがコメントを持っているわけではないので、生成されたドキュメントは十分に我々の書いた概要を含んでいません。しかし、私は Doxygen が重要な情報を自動的に生成するので、そのドキュメントはあなたにとって有益だと思います。

私はまた風邪を引いてしまいました。 最近、私は週末になったら風邪をひいています。私のブログは2日間更新されませんでした……

さて… 私たちはXOOPS Cube2.1のユーザモジュールで多くのファイルをチューンアップしました。そして、私はいくつかの重要なフィーチャーがAlpha3から4への変化の中で動作不良を起こしていることを知るに至りました。 グローバルサーチサービスは古いXCube_Serviceのクラスと共に開発されました。しかし、XCube_Serviceがかなり変わってしまったので、現在、それは動きません。XCube名前空間のデザインはBeta2で決定されるでしょう。 したがって、今は私たちは一時的なデザインでこのクラスを修復するつもりです。

ユーザモジュールのすべての動作フォームは既に調整済みです。それらのクラスにも、多くの問題がありました。加えて、 cubson が時々アップデートされたために、アクションクラスのすべてが一様ではないという別の問題もあります。それらのコードをきれいにするために、私たちは手作業で部分修正をしなければなりませんでした。 そのような問題はcubsonの弱点の1つです。

そのほか、Alpha3のいくつかの重要な欠陥がいくつかのすばらしいレポートによって修正されました。私たちは偉大なレポーターの協力に感謝します。

私は、明日CVSにこれらの変更をコミットするつもりです。

私たちの崩れたロードマップを回復するために、XOOPS CubeのCVSは日々アップデートされています。そして、開発者がCVSにアップデートしたソースコードをコミットするとき、あなたは特別なメーリングリストによって通知を受け取ることができます。 通知は下手な英語のコメントと diff が書かれています。あなたがコア開発チームの動きが気になるのであれば、このMLは役に立ちます。

通知を受け取り始めるために、あなたはこのページであなたのメールアドレスを登録しなければなりません。 登録ページは日本語で書かれています。 しかし、通知が英語で書かれているので、心配しないでください。 以下のイメージを見てください。あなたはメールアドレス、パスワードと、確認パスワードを以下のテキストボックスに書くことができます。

さらに、ファイルにおけるコメントは決して完璧ではありませんが、いくつかの役に立つ情報を含んでいます。CVSに関するログとこれらのコメントは変更を理解しやすくするでしょう。

現在、XOOPS Cube開発チームはXCube_Serviceのテスト版とその可能性をレビューしています。 私たちはサービスクライアントに関して既に基本的な抽象化レイヤーを開発しました。それは、ただアダプターであるので非常に簡単でした。 そして、私たちは、その開発でアダプターが複合条件下の抽象化レイヤーの単純な解決策であることを学びました。しかし、抽象的なクライアントは簡単な課題です（それには内側のサービスと外側のサービスの違いが全くありませんから）。

しかしながら、抽象的なサービスには、ウェブサービスとして働くための多くのパラメータがなければなりません。 内側のサービスであるなら、それはWSDLのために厳しい定義を必要としません。 しかし、ユーザがウェブサービスとしてそれを動かすとき、それが内側のサービスであるか否かに関係なく、そのサービスには厳しい定義がなければなりません。 これらの問題は以前、書かれたことがあります。

私たちは、用法をテストするためにサンプルモジュールを作らなければなりません。 私は、既に1つのモジュールと3つのハッキングファイルを開発して、これらのファイルを開発チームに送りました。 これらのファイルは、XCube_Serviceクラス群が正しく働くのをチェックすることができます。しかし、これらのファイルの機能は冗談みたいなものです（その冗談はXCube_Serviceに関して少しの可能性も示しません）。 多くのユーザが抽象的なサービスで遊べるようになるように、私たちはXCube_Serviceの特徴を使用するいくつかのおもしろいモジュールを計画しなければなりません。

XOOPS Cubeはウェブサービスの特徴を得るでしょう。 しかし、私はおもしろい体験をすべてのユーザにもたらすキラーモジュールを想像することができていません。モジュールが大差なしでクライアントとサービスを切り換えることができるなら、モジュールはP2Pのような特徴を得るかもしれませんが……

次の問題は内側のウェブサービスと、外側のウェブサービスが異なるかもしれないという可能性です。 それは重大な問題です。 XCube_Serviceには、内側のサービスと外側のサービスの違いを吸収するフィーチャーを持っています。しかし、もし開発者がそれ必要としなかったら……？　内側のXCubeサービスは外側のサイトのコンテンツを一切含めないことを要求されるかもしれません。

サービスのクラスは書きやすいなら、それは問題ではありません。 2種類のクラスを準備するのは、良い解決策でしょう。しかし、残念なことに、サービスのクラスは開発者に厳しい定義を要求します。 したがって、それは即席には書きにくいです。 恐らく、XoopsObjectHandlerはモジュールコンテンツのコンテンツをリレーすることに関しては、サービスクラスより素晴らしいメカニズムです。 もちろん、ウェブサービスに接続させるために、ハンドラを抽象化することは可能です。XoopsObjectHandlerのデザインはこのような点において、非常に優れています。

しかし、ウェブサービスへの抽象的なレイヤーは今の時代にたいへん重要です。他のモジュールのコンテンツをリレーするだけ、ということは、重要ではありません。そのような場合でも、XOOPS Cubeは近い将来他のサイトに接続できることを要求されるでしょう。 たった1つのクラスを書くことによって、他のモジュールと他のサイトの両方にコンテンツをリレーすることが実現できれば、それは理想です。

ほとんどの開発者はXoopsObjectHandlerとXCube_Serviceの両方とも使用しないでしょう。しかし、他のモジュールか1File HackingでXCube_Serviceをモジュールに追加することは可能です。 私たちはクラスの目的を明確にしなければなりません。それによって、クラスのコードはシンプルになります。 お気づきのように、私たちはRoadmapに示されるベータ系列に取り組んでいます。 ある複雑な因果関係によって、私たちはコードをブラッシュアップして、XCube名前空間を再設計するという並行開発をしなければなりません。XShadeとexReviewは良いテストです。

XCube_ServiceはXCube名前空間のCVSの未完成のクラスの1つです。 このクラスには、以下の目標があります:

• 通常、このクラスは、モジュール間接続に使用されます。
• デリゲートは、一種の関数ポインタであって、このクラスとは似て非なるものです。
• ユーザはWebサービス・アダプターへどんなXCubeサービスも適合させることができます。
• また、ユーザはどんなXCubeサービスクライアントもWebサービスに接続することができます。

しかし、多くの問題があります。 第1の問題はLegacyモジュールが何をWebサービスライブラリとして収録するかということです。Legacyモジュール群はGPLであり、私たちがそのライセンスを変えることはできません。私は、それがGPLである以上は、LegacyパッケージがPEARライブラリを直に収録することはできないと考えています。しかし、フルスクラッチ・プログラムであるXCube名前空間はデュアルライセンスを用いてGPLから離れることが可能です。例えば、テストBaseモジュールであるXOOPS Cube Shadeは別のライセンスを持っています。 言い換えれば、XShadeはGPLライブラリだけではなく、PEARライブラリを持つことができるということです。

したがって、私たちは、Baseモジュール側にウェブサービスを実装するためのライブラリを持たせなければなりません。 そして、XCube名前空間には、特定のライブラリがあるべきではないでしょう。それぞれのBaseモジュールがライブラリと、アダプターのインスタンスを作成する Factory のためのデリゲートを持つことが必要です。

今日、ウェブサービスに関するクラスデザインのテストためのexReviewはsf.jpのexmodulesプロジェクトにコミットされました。このモジュールはXCube名前空間の抽象レイヤーを伴わず、未だWebサービスを直接インプリメントしています。 言い換えれば、現在のXCube_Serviceでウェブサービスを実装することは、困難で、間違っているのです。

私は次の金曜日、土曜日、日曜日にブログを更新しません。その理由は昨日のエントリに書きました。本日のエントリは今週最後のエントリです。私は面白いイベントを告知します。

「XOOPS Cube Tokai Conference 2006 (XTC2006) -- 決戦は名古屋。でたがや！ XOOPS Cube」は名古屋で７月２９日に開催されます。その長いタイトルは何ですかって？　えーと、これは（おそらく）日本ではクールな表現なのです。

これは、東海の最初の XOOPS イベントです (東海は日本の地域のひとつであり、この前の万国博覧会によって知られています）。東海で生活する Tom_G3X は、このイベントを企画しました。そして、彼、及び、彼の友人は、現在、開催に備えて準備しています。

多くの開発者は、東京からのこのイベントに行くでしょう。もちろん、私も、行くつもりです。我々は、東京の我々のイベントに Tom_G3X を常に巻き込みました。今回は、我々の順番です。

私は、 cubson GUI 版の demo ムービーを上映するつもりです。Cubson GUI 版は、ナンセンスな考え(大部分のウェブ開発者が考えようとも思わない) によって開発された奇異なソフトウェアです。そのデモムービーは、ネットで公開されません。イベントの後で、私は、このサイトで、デモムービーの代わりに cubson GUI 版の要約を公表するでしょう。あなたがその詳細を見ることを望むならば、イベントへ出かけましょう！

誰でも無料でこのカンファレンスに入場可能です。もし、カンファレンス後の宴会に行きたいのであれば、4,000円を実費として支払わなければなりません。カンファレンスと宴会は定員があります。これらの催しにここからアプライできます。

東海とは？

東海は、名古屋や豊田等々を持つ日本の地域です。二つの都市はよく知られています。特に、豊田市は自動車メーカーのトヨタ社の拠点として有名です。

余談ながら、私は以前東海に住んでいたことがあります。

XCube は、本格的なフレームワークを持っていません。なぜなら、それは、開発フレームワークではないからです。「フレームワーク」は PHP にとって特別な意味を持つようになっており、 PHP プログラマを刺激します。ですから、私は、余計な討論を誘発しないためにこの「フレームワーク」という単語を使いたくないのです。
（「フレームワーク」は、ウェブプログラムの世界で特別な待遇を受けています。私は、「フレームワーク」の代わりに日本語の「枠組み」を使おうと考えました。しかし「枠組み」の意味は、フレームワークなのです……）

XCube_Controller は、コントローラクラスです。XOOPS2 構造はうまくコントローラを持つことができないので、それは、 Legacy 2.1 において仮想コントローラと呼ばれています。モジュールは、コントローラにアクセスしなくても、機能することができます。開発者は、コーディングスタイルを変える必要がありません。

XCube_Controller は、モジュールプロセスについて空のメンバ関数を持っています。それは、 execute() です。そのメンバ関数は、 XCube_Controller のメンバプロパティである XCube_ActionStrategy のオブジェクトに（具体的処理を）委託します。そのメンバプロパティのデフォルト値は、 NULL です。つまり、あなたが方針を設定するまで、 XCube_Controller は、フレームワークとして機能しません。あなたは、あなたの ActionStrategy を作成し、そして、それを XCube_Controller に埋め込むことができます。そう、つまり、着脱式だということです。

ご存じのように、 Legacy は、フレームワーク・プログラミング・ライクなコードを多く含みます。しかし、私達は、それを開発者に強要することはしません。そして、そのフレームワークは、 Legacy のフィーチャーではありません。class/ ディレクトリを見てください。私達は、モジュール毎に XCube_ActionStrategy のサブ‐クラスを定義しました。

あなたが本職であるならば、あなたは、 mojavi2 や exFrame::mojaLE より簡素である Legacy の簡易フレームワークを使うことを望まないでしょう。私は、余計な討論を誘発しないために、行き過ぎなほどシンプルにそれを設計しました。それは、私が多くの注意を払った部分です。

このような情況は、私にストレスを加えました。そして、PHP 世界を知るために、私は、それを研究することを望みました。しかし、私は PHP 世界を研究するための十分な時間を保持できませんでした。それが私にとって別世界であるということは残念です。

しかし、私が思うに、大部分の開発者は、着脱式メインロジック方式である ActionStrategy があるので、「枠組み」が問題であるとは考えないでしょう。

XOOPS Cube2.1アルファー3はもうすぐやってきます。通知以外のすべてのXOOPS2の特徴のほとんどが Legacy モジュールでエミュレートされます。いくつかの特徴はDelegateによって実装されます。

例えば、backend.phpは一度削除されました。 古いバックエンドはニュースモジュールに依存しています。しかし、ニュースモジュールはXC2.1パッケージから取り外してあります。 したがって、どんなものにも、バックエンドは有効ではありません。 そこで、それはDelegateで再び書かれました。1File Hackingか、モジュールのデフォルトプリロードでモジュールのRSS機能を加えることができます。 あなたは、PreloadメカニズムとDelegateメカニズムを知っているので、新しいバックエンドを理解することができると思います。

ところで、あなたは、XOOPS CubeがXOOPSからフォークしたものではないことを知っていますか? 私たちはゼロからプログラムを作り始めました:

オフィシャル・ドキュメントには、間違ったコンテンツがありました。 私たちは、XOOPS 2.0.xシリーズがXOOPS Cubeに含められたと説明しました。 しかし、それは間違っています。 xoopscube.orgとxoopscube.jpを始めたとき、私たちはホームページで「XOOPS」を「XOOPS Cube」に取り替えました。それがオフィシャル・ドキュメントに間違った内容があった理由です。

事実はこのダイアログによって示されます。 XOOPS Cubeは新しいフィールドです。Legacy モジュールはXOOPS Cubeで働いて、XOOPS2 JPに関するいくつかの古いファイルを含み、そして、XOOPS2 JPをエミュレートします。私たちは将来、Legacyを捨てるつもりです。次のXOOPS Cubeの新しいベースパッケージはXOOPS2のコードを含まないでしょう。

オフィシャル・ドキュメントは現在、正しい説明に変更されました。

XoopsObject は、XOOPS で最も悪いクラスののうちの１つです。Onokazu さんもそれを認めました。しかし、今になって新しいクラスを導入することは、難しいです。私が思うに、大部分のモジュール開発は、 RAD ベースになるでしょう。従って、クラスのコードがクリーンアップされるならば、問題は少ないといえます。

私達は、 XoopsSimpleObject 、及び、 XoopsObjectGenericHandler を作りました。XoopsSimpleObject は、我々が抽出した XoopsObject の共通インターフェースを実装します。クラスダイアログを見てください :


XoopsObject は、非推奨になりました。しかし、 XoopsSimpleObject は、独自のクラス、もしくは、有名なライブラリを持たないビギナーにとって便利です。XoopsSimpleObject は、タイプセーフ特徴、シンプルなアクセスメソッド、 BOOL INT FLOAT STRING TEXT である 5 つの DTYPE を持っています。Criteira クラスは、 SQL から分離され、そして、 XoopsObjectGenericHandler は、型安全性と共に Criteria によって SQL を生成します。

Criteria クラスは動的 SQL のための情報構造体に変わりました。Criteria::render() は XC 2.1 では非推奨です。

加えて、いくつかのツールが、開発者をサポートします。私は、直接 XoopsSimpleObject のサブクラスを書いたことがありません。XoopsSimpleObject を使うために常にツールを使っています。私は、自分より機械を信用しているのです。

私達は、それを強要することはしません。しかし、開発者が DB にアクセスする際の問題を理解しないのでならば、彼は、 XoopsSimpleObject やツールを使うべきだと考えます。

ところで、 XoopsObject には、多くの短所と、いくらかのメリットがあります。 Criteria::render() が XC 2.1 で非推奨ですから、あなたは、それを何にでも使うことができます。XoopsObject は、ハンドラによって DB から分離されます。従って、 XoopsObject 、ハンドラ、及び、Crteiraは、抽象的です。あなたは、そのようなクラスを使うことによってWebサービスを使うことができます。

$handler =& gethandler(...);
$criteria = ...;
$objs =& $handler->getObjects($criteria);

開発者は、どこからオブジェクトを得たかを知る必要がありません。それは、 DB 、または、WEBサービスであるかもしれません。しかし、 DB 、WEBサービスにかかわりなく、開発者は、彼らのコードを変える必要がありません。私が思うに、このことは、近い将来重要になるでしょう。それは、ブリッジ技術にとって有益なように思われます。

しかし、その感覚は、私がアマチュアである私の経験から来たかもしれません。それは、専門家には役に立たないかもしれません。

XOOPS Cube Developers Ring は XOOPS における Third Way です。Xoops オフィシャルは中央集権的です。そして、彼らは基金を設立しました。XOOPS Cube オフィシャルは（幻想の）ヒエラルキー構造と、オフィシャルと 3rd Party の違い（という感覚）を打ち砕こうとしています。誰も、オープンソースで政争を楽しみたいとは思いません。また、私たちは基金やNPOを設立することに時間を費やしたいとも思いません。

私たちの理想は、ユーザがいくつかの基点となるXOOPSユーザ・グループサイトを造って、互いにコネクトすることです。「公式か？それとも非公式か？」そのような感覚はありません。または、ユーザは彼らのために彼らの公式サイトについて決めるでしょう。例えば、GIJOE は XOOPS と Cube の公式サイトを訪問するのを止めるようになりました。しかし、彼はfabiさんと彼の友人が造ったXoopsユーザグループ日本に参加しています。

XC Dev Ring は公式ともユーザ・グループとも異なっています。開発者を1つのサイトにとどまらせることは難しいことです。これは、友人同士が XOOPS と XOOPS Cube の如何にかかわらず相互に接続するという挑戦です。そして、それはXOOPSユーザのひとりである minahito(私) によって始められました。したがって、公式も非公式もありません。私の振舞いが悪いなら、他のメンバーは私へのリンクを削除します。 そして、私がXOOPS Cubeから離れた後であっても、リングは保たれるでしょう。

ところで、XC Dev Ring "JP" と XC Dev Ring "EN" は異なっています。"JP" には、8人の日本人メンバーがいます。 "EN"には、英語を書く2人の日本人メンバーがいます。Dev Ring は技術的メカニズムではないので、だれでも、自身の国または自分の言語で同様のRingを造ることができます。もちろん、あなたが英語で書くなら、私とGIJOEは英語のリングにあなたを歓迎します。もしくは、あなたは新しい友人リングを組立てることができます。

不完全なルール

• メンバーは RSS をブログかニュースの上で発行しなければならない。
• 開発の話題をときどき書いてください。
• 次のメンバーは前のメンバーの RSS を受け取らなければならない。
• 最初のメンバーは、環状構造のために、最後のメンバーの RSS を受け取らなければならない。

XOOPS Cube Legacy 2.1 (XC 2.1) は管理画面でヘルプビューアを実装しました。もともと$modversion['help']はXOOPS2で予約されていました。しかし、それは何処にも使用されませんでした。XC2.1では、開発者はヘルプドキュメントをモジュールに添付することができ、そして、ユーザはコントロールパネル上で直接そのドキュメントを読むことができます。

ドキュメントの添付方法

ヘルプドキュメントをあなたのモジュールに添付しましょう。 初めに、$modversion['help']にインデックスファイル名を書いてください。このファイルは、ユーザがコントロールパネルのサイドメニューでヘルプをクリックしたときに、最初に表示されるページです。私は今回、それを"help.html"と命名します。

次に実際の"help.html"を language/english の中に作成してください。そうです、ヘルプビューアはマルチリンガルドキュメントに対応しています。もしあなたが、フランス語、スペイン語その他のドキュメントを持ちたいのであれば、それぞれの言語ディレクトリ内に同名のファイルを作ってください。

最後に、ドキュメントを書きましょう！

別のページにリンクする方法

ヘルプドキュメントはPHPによって表示されます。ヘルプのURLはPHPアプリケーションのページのアドレスになるため、相対リンクで（ヘルプ内の）他のページにリンクすることは困難です。

しかし、ヘルプドキュメントは純粋なSmartyによってロードされ表示されます。そして、特別なSmartyのプラグインはURLに関するいくつかの問題を解決してくれます。 helpurl は、ヘルプビューアのみで使用されるSmartyモディファイアです。

他のページへリンクするために、ヘルプドキュメント内で次のようなURLを書いてください。

<a href="<{'page2.html'|helpurl}>">The detail of functions</a>

ドキュメントで画像を使う方法

同様の原因で、ヘルプドキュメント内で画像を（相対リンクで）使うことができません。この問題を解決するためにSmartyモディファイアのhelpimageを使うべきです。

画像ファイルを language/****/helpimages ディレクトリに配置してください。キャプチャーイメージは各言語の文字を含むため、ヘルプビューアは、ドキュメントと同様にマルチリンガルなイメージファイルに対応しています。それから img タグを次のように書いてください:

<img src="<{'screenshot01.jpg'|helpimage}>" alt="..." />

イメージ・ファイルがユーザが指定した言語のディレクトリに存在していないなら、モディファイアはenglishディレクトリからデフォルトのイメージ・ファイルを手に入れようとします。 したがって、あなたは大量のイメージ・ファイルをすべての言語のために作成する必要はありません。

規則

私たちは、ヘルプのために特別なCSSを準備する計画を立てています。開発は原則そのCSSに従ってください。 現在のヘルプビューアの外観は調整されていません。デザイナーは、XC2.1アルファー4でCSSをクールに調整して、その規則を発表するでしょう。

C# は、デリゲートをイベントとして用います。イベントは、 C# の優れたフィーチャーのひとつであり、コンポーネントにおいてイベント・ドリブンなプログラミングのために使われています。

XOOPS Cubeも、イベントの概念を持っています。しかし、それはデリゲートとイベントを区別しません。私は、コアチームはデリゲートについてクラス設計を変更する計画を持っていると書きました。その計画は、XOOPS Cubeにこれらの概念を分離させるということです。将来、このエントリのサンプル・コードが動作しないであろうことに注意してください。

さて、 XOOPS Cube のイベントを学びましょう。現在、XOOPS Cube のイベントは、デリゲートと同じものです。あなたは、デリゲートとしてあなたの関数をイベントに登録することができ、そして、そのイベントが発生したとき、イベントはあなたのデリゲートを呼びます。

例えば、ユーザーがログインに成功すると、Module.User.Login.Successイベントが発生します。その引数は、 XoopsUser オブジェクトです。実際、デフォルトのデリゲートのうちのひとつは、オブジェクトの最終ログイン時刻に現在の時間を記録します。あなたは、デリゲートとしてのあなたの関数をこのイベントに追加できます。

日本のユーザーの間でポピュラーなセキュリティ・ハックがあります。それは、特定の IP を除いて、管理者としてのログインを許可しないという機能を持っています。このハックは、会社や、管理者のパスワードが盗まれたケースへのガードに有効です。XOOPS2 においては、そのハックは、直接 common.php 、または、 admin.php に書かれなければなりませんでした。XOOPS Cube Legacy 2.1 においては、ユーザーがログインに成功したときに、デリゲートを使うことで自前の関数を実行できます。あとは、あなたの関数が、特定のIP以外を跳ね返せばよいのです。

あなたは、それを Site.Login に登録すべきです。もしアタッカーがセッションハイジャックを行えば、彼は Module.User.Login.Success を通過しないかも知れません。しかし、 "Site.Login" は、常に呼ばれます。

if (!defined('XOOPS_ROOT_PATH')) exit();

define("ALLOW_AS_ADMIN_IP", "127.0.0.1");

class IPChecker extends XCube_ActionFilter
{
    function preBlockFilter()
    {
        $delegate =& new XCube_Delegate("IPChecker", "siteLogin");
        $this->mController->mRoot->mEventManager->add("Site.Login", $delegate);
    }

    function siteLoginSuccess(&$sender, &$eventArgs)
    {
        //
        // Delegate doesn't know own turn. Call static function
        // of the user module to login.
        //
        if (!is_object($eventArgs->mXoopsUser)) {
            UserCommonEventFunction::Login($sender, $eventArgs);
        }
        
        //
        // If the current user is guest, return.
        //
        if (!is_object($eventArgs->mXoopsUser)) {
            return $eventArgs;
        }
        
        //
        // If the current user is a administrator, check IP.
        //
        if ($eventArgs->mXoopsUser->isAdmin()
            && $_SERVER['SERVER_ADDR'] != ALLOW_AS_ADMIN_IP) {
            $_SESSION = array();
            $sender->executeForward(XOOPS_URL . "/");
            die();
        }
        
        return $eventArgs;
    }
}

このファイルを XOOPS_ROOT_PATH/preload/IPChecker.class.php に保存してください。

さて……このような機能は XOOPS Cube の本体に含めることが可能です。しかし、一部の人のみが必要とするリクエストが、どれくらいあるでしょうか？　一体だれが、これらのコードを取り込んで、管理して、メンテナンスできるでしょうか？　肥満プログラムは、えてして良好なメンテナンスを失いがちです。私達は、小さなコアを選択しました。それはそれほど多くの機能を内蔵していません。しかし、プリロードとデリゲートは新しいハック手段と共有をもたらすでしょう。

ユーザーのアイデアは、しばしばコアを超越します。そして、ユーザーは、これらのアイデアのうち必要なものだけをセットすることができるのです。

デリゲートは、本質的にコールバック・メカニズムです。デリゲートによって、コールバック・プログラミングの全ての長所を利用することができます。交換可能性においては、クラス継承もデリゲートと同様に役に立ちます。したがって、クラス継承とデリゲートを区別して使い分けることが、重要になってくると思われます。そのために、クラス継承とデリゲートの特性の違いを理解する必要があるでしょう。

以下のクラスを見てください。

1. PMMonitor と呼ばれているこのクラスは、１週間読まれていないプライベートメッセージを持つユーザーをリストアップして、彼らにメールを送ります。
2. このクラスを使用するコードは、ブロックに含まれています。
3. その機能は、ブロックをサイトに置くことによって動作中になります。

言い換えると、プログラム・カウンタは、このクラスのコードを通過（実行）します。

さて、あなたは、このクラスが管理者に CC を送ることができるならば、それが自分にとってより便利になると考えました。そして、あなたはサブクラスを定義して、CC を送るために基底クラスをオーバーライドしました。



しかし、それは動作しません。他のコードが、あなたが新作したサブクラスの名前を知らないため、そのサブクラスは、どこからも呼ばれません。言い換えると、プログラムカウンタは決してこのサブクラスを通過しません。あなたがサブクラスのインスタンスを作成するコードで、基底クラスのインスタンスを作る元のコードを取り替えるまで、あなたのサブクラスは機能しないでしょう。

クラス継承は、プログラム上で開発者に機能を交換する可能性をもたらします。しかし、それはソースコードの変更を必要とします。 PMMonitor がデリゲートを持っていれば、機能を交換するか、機能を加えるためにそれを活用することができます。この場合、サブクラスを定義して他の箇所のソースコードを変更する必要はありません。

デリゲートを持つクラスが「PMMonitorDash」であると仮定しましょう。PMMonitorDash は、固定機能の代わりにデリゲートを使います。したがって、 PMMonitorDash のデリゲートにあなたの関数を登録すれば、あなたのコードが PMMonitorDash で働くことになります。



XOOPS Cube ではカスタマイズするために基本クラス群を取り替えることができます。それは、最も抜本的な改造方法ですが、しかし、ハードワークでもあります。ユーザーは、それを最後の手段と呼ぶかもしれません。その点、デリゲートは XOOPS Cube で最も簡単な改造方法になるでしょう。

デリゲートは、 XOOPS Cube における新しいフィーチャーです。それは、統一的なコールバック手続きということになります。開発者は関数と同様にそれを使うことができます。そして、それは、交換可能性をもたらします。しかし、私達は XOOPS Cube 2.1 RC バージョンまでに Delegate に関するいくらかのクラスの設計を変える予定です。この計画は、このエントリシリーズのサンプルソースコードに関する問題を誘発します。

デリゲートは、Ｃ＃、Ｄ言語 、及び、いくらかのプログラミング言語のが持つフィーチャーです。それは、ファンクションポインタのようなものです。ご存じのように、プログラムは、コンピュータの原始時代からファンクションポインタのようなものを使用してきました。それは、アドレスレジスタによって指定されるアドレスへのジャンプです。

本来であれば、 XOOPS Cube が、 PHP でコールバックのための手続きを定義する必要はありません。PHP は、コールバックのための関数を持っており、そして、プログラマはいくつかの方法をコールバックに使うことができます。しかしながら、プログラマが彼のすべての関数にプラグイン・メカニズムの実装を試みるのであれば、彼はプログラミングと説明に多大な時間と努力を払わなければなりません。

プログラマは、プラグインファイルをロードし、関数をチェックし、コールバックを実行するプログラムを組まなければなりません。プラグイン・メカニズムを持ついくらかの XOOPS モジュールを見てください。これらのモジュールのコールバックのための方法は、すべて異なります。そして、もし、コールバックについて設計されていないモジュールへプラグイン・メカニズムを付け加えるならば、それは大変な作業になるでしょう。

デリゲートはは、統一されたコールバック手続きによってこれらの問題を解決します :

• プログラマは、彼の関数を C# と同様に、デリゲートに変更できます。
• プラグイン開発者は、 XCube_Delegate メカニズムのみ学習すれば大丈夫です。
• プラグイン・ファイルをロードすることについて考える必要はありません。（プリロードメカニズムを思い出してください）

モジュール開発者は、最初にコールバックなしでプログラムを完成させることができます。次に、リファクタリング・ツール、もしくは、手動によって通常の関数をデリゲートに変更します。この２ステップによって、交換可能なモジュールが、今まさに完成しました !

もし、コアがデリゲートとしてのトラックバック関数を持っているのであれば、ユーザーは、それをモジュール、または、 1 File Hackings が持つ他の関数と交換し得ます。私は、デリゲートなしの XOOPS Cube を想像できません。デリゲートは、コア開発、モジュール開発、カスタマイジングにとって便利です。

私は XOOPS Cube のためのいくつかの Windows アプリケーションを開発しています。

For Development

私はcubosonとcubson GUI Forceをリリースするつもりです。 Cubson GUI ForceはcubsonのGUI版です。 それは私が考える新しいモジュール開発スタイルを実現します。Cubson CUIはプログラムを作るのを楽しむプログラマーのために作られています。しかし、Cubson GUIはXOOPS Cubeを楽しみたがっているすべての人のためのおもちゃです。

Cubson GUI Force は私が長い間求めていたものになるでしょう。しかし、それは十分ではありません。私は設計段階からRADのために設計されている理想的なCMSを求めています。 私は次回、それについて書くつもりです。

特別なDLLを使用するので、現在、Cubsonはクローズソースです。私はcubsonの最新のソースコードからそれを既に取り除きました。しかし、まだコンパイルに対して完全ではありません。

For Destribution

ディストリビューターはXOOPS Cubeの新しい重要な存在です。それはユーザ・グループの一種です。彼らは、彼らが望む１つのベース・モジュールといくつかのモジュールから成るオリジナルのパッケージを配布します。それらはユーザの中心になるでしょう。

彼らのためにパッケージを自動的に作成する特別なツールが必須になります。そして、それは GUI ツールであるべきです。 彼らがマウスだけでパッケージを作成することが可能なツールが存在しないならば、ディストリビューション・グループは現れないでしょう。

For Management

自動アップデートのための手段はしばしば検討されます。それらのうちの１つはPEARのような仕組みです。それは、いい方法であり、だれかによって作られるでしょう。私が考える手段は、FTPプロトコルを直接使って、最新のプログラムを手に入れて、それをユーザのサーバにプットする自動メンテナンス・アプリケーションです。サーバのパーミッションに関する設定が必須ではないので、初心者にとって、そのようなアプリケーションはお手頃だと考えます。もちろん、このアプリケーションの目標は、GUIとマウス専用です。

すべてのモジュールとテーマは、自己の情報をそのようなアプリケーションに示すために、package.ini.php というファイル名のマニフェストを持つようになるでしょう。テーマには、マニフェストが既に導入されてます。しかし、マニフェストの形式はまだフィックスしていません。

1File HackingとModuleの違いはどのようなものでしょうか？　 例えば、あなたのサイトが家だとしましょう。モジュール、１ファイルハッキング、および他の要素は次のように考えることができます:

• コアは土地です
• モジュールは柱です
• １ファイルハッキングはデコレーションです
• (ディストリビューションはモデルハウスです)

モジュールには、素晴らしいコンセプトがあります。 しかし、それは大きめの仕事です。プログラムを作ることができたとしても、ほとんどのユーザはサイト・カスタマイズのためだけにモジュールを作ろうとしません。 一方で、軽量できめ細かいカスタマイズをもたらす１ファイルハッキングを手にするでしょう。ユーザにとって、専用の１ファイルハッキングを作ることは全く問題がありません。 (もちろん、彼はそれを共有することができます)

１ファイルハッキングはXOOPSの使い方を変えるかもしれません。XOOPS Cubeのインストール手順は次のようになるでしょう。

1. パッケージをお気に入りのディストリビューションからダウンロードします
2. XOOPS Cube本体とパッケージをインストールします
3. 好みのモジュールをインストールします
4. 好みの１ファイルハッキングをインストールし、チューン・アップを行います。もしくは、１ファイルハッキングを自作して、それを公開します。

私は、１ファイルハッキングが、バージョンアップを難しくする直接的ハッキングの大半に取って代わることを期待しています。また、サイト・オーナーは彼らのフォーラムで、この１ファイルハッキングに関する新しいトピックを得るでしょう。

XOOPS Cubeのデリゲート・メカニズムはPreloadの可能性のすべてを発揮させることができます。 OSC2006/Springでは、Nobunobuさんが1個のファイルだけでbbcodeに関するtextsanitizerの動作を変更するデモを示しました。 それはデリゲート・メカニズムを使用しました。 もちろん、デリゲートを使わない１ファイルハッキングであっても、問題ありません。私は近い将来、デリゲートについて説明するつもりです。

1 ファイルハッキングはXOOPS Cubeの新しいカスタム手段につけられたニックネームです。それはPreloadとActionFilterの組み合わせによって実現されます。サイト・オーナーはピンポイント・カスタマイズにそれを使用します。

Preloadは初期化コードをXOOPS Cubeの手続きに追加するメカニズムです（DOSのバッチ・ファイルを想像してください）。ActionFilterは初期値設定のためのmojaviライクなクラスです。CVS上の最新の2.1では、Preloadの規則は以下のようになっています:

• /setting/site_default.ini.php の AutoPreload 値は真でなければなりません。しかし、それがデフォルト値であるので、あなたはそれを編集する必要はありません。
• 拡張子が'.class.php' であるファイルを作成してください。
• そのファイルで XCube_ActionFilter を拡張するクラスを定義してください。
• そのクラス名は、そのファイルのボディー名と等しくなければなりません。

私は実例を用いて１ファイルハッキングのPreloadを説明します。あなたは XOOPS Protector をご存じかと思います。GIJOEさんはXOOPS Protecorの最大効果のために、mainfile.phpをハックすることを勧めています。ハックされたmainfile.phpと同様に動作するファイルを作成しましょう:

1. XOOPS_ROOT_PATH/preload ディレクトリ内で 'ProtectorLoader.class.php' ファイルを作成してください。
2. 以下のコードをプログラムしてください:

class ProtectorLoader extends XCube_ActionFilter
{
  function preFilter()
  {
    include( XOOPS_ROOT_PATH . '/modules/protector/include/precheck.inc.php' ) ;
  }

  function preBlockFilter()
  {
    include( XOOPS_ROOT_PATH . '/modules/protector/include/postcheck.inc.php' ) ;
  }
}

ミッション・コンプリートです。 このファイルは、共有するのによいでしょう。 何らかのモジュールをインストールした後に、サイト・オーナーはこのようなファイルでサイトをチューン・アップすることができます。

ノート:

あなたはX11ライセンスの下で、このエントリーを扱うことができます。 しかし、このエントリーは毎日成長するXOOPS Cubeアルファーバージョンに依存しています。あなたはそのことに注意しなければなりません。
(日本では、著作権を放棄することはできませんが、X11ライセンスは日本の著作権法に矛盾しません)

なお、公式の仕様が定められた際に、公式のテクニカル・ドキュメントが公開されるでしょう。

GIJOEさんは、記事の中でポリモフィズムのためにXOOPS_TRUST_PATH^[1]を利用することを提案しました。それは良いアイデアです。 Nuke と PageController の組み合わせは、'複製可能'のためのいくつかの弱点を持っています。それに関するエクセレントなコードを書くことはなかなか難しいといえます。GIJOEさんはそのような問題を解決しようとしています。

私は以前、私の会社に関するイントラネット・ウェブ・プログラムで同様のメカニズムを実現する面白いコードを見かけました。私はそれの詳細を書くことができませんが、おおむね以下のようなものでした:

define_class('myData', 'tableA');
$instance = new myDataHandler();

function define_class($className, $tableName)
{
  //
  // Define class
  //
  $code = "class {T}_Handler {" ...

  $code = str_replace("{T}", $className);
  $code = str_replace("{table}", $tableName);

  eval($code);
}

これはeval()による簡単なC++テンプレートメカニズムです。実行コードが直接関数に書かれているので、これはほとんど安全です。 私は、それからヒントを得て、extools^[2]のClassTemplateを開発しました。

eval()は、XOOPSにおいて'複製可能'メカニズムのためによく使用されます。 C++ライクなテンプレートメカニズムはeval()の使用のための統一手順ということになります。それは設計を気楽にしてくれるかもしれません。しかし、eval()はしばしばセキュリティーホールを作ります。 このような使用方法をするときがきたら、十分注意してください。

---
^[1] XOOPS_TRUST_PATHはウェブブラウザがアクセスすることができない安全なディレクトリです。
^[2] extools はexFrame(XOOPSクラスライブラリ)のためのコードジェネレータです。

Xoops User Group Japan はXOOPS Cubeコミュニティの最初のユーザ・グループです。 彼らは、XOOPSのマニュアルを仕上げて、他のマニュアルを書き始めました。 そして、彼らは他のものに挑戦しています。

それらの成果物を公式サイトに追加したがっている人がいるかもしれません。 確かに、ユーザのすべての投稿が集められるサイトは便利であるかもしれません。 しかし、それは一部のサボリの願望です。大き過ぎる公式サイトとパワーはナンセンスな問題の引き金となるでしょう。 熱心なユーザの行動力を妨害するべきではありません。

そして、私たちが新しいウェブ技術を使用することによって複数のサイトをつなげることができるのを忘れないでください。「アグリケーション」は「統一」より良いでしょう。ティム・オライリーは、1つのサイトに対する忠誠心が現在古い要素であると主張しました。

さて、XUGJの他のコンテンツを見ていきましょう：

XOOPS Dictionary

これはXOOPSに関する辞書です。 あなたは辞書で専門用語を調べることができます。また、フォーラムの投稿からwikilinksに似ているものを用いることで辞書のすべての単語をリンクすることができます。その機能はGIJOEさんの素晴らしい仕事です。

XOOPS Cube2.1では、そのようなハッキングは、Delegateメカニズムを使用することによって、実装されるでしょう。 私は近いうちに、それに関して書くつもりです。

Xoops Q&A

このコーナーは質問して、それに答える特別なフォーラムです。うまく答えたとき、あなたはポイントを得ることができます。plzXoo(教えて！Xoo)モジュールがこのコーナーで使用されています。しかし、それは標準のヘボいplzXooではありません。 GIJOEさんはこのコーナーのためにすばらしい Alternative バージョンを開発しました。

私は、plzXooがうまく使用されるのを一度も見たことがありませんでした。しかし、Alternative バージョンはうまく機能するように見えます。私たちは Alternative バージョンの機能だけではなく、管理者の方々の良い仕事にも注意を向けなければなりません。

XOOPS CubeコアチームはXOOPS Cubeコミュニティの中央集権体制化に反対しています。 私たちは、XOOPS Cubeコミュニティが複数のサイトに分散されることを願っています。 このスタイルは自由と相互尊重をもたらすでしょう。

XOOPS.org の流儀は中央集権体制です。それは、たいへんパワフルで素晴らしいものです。しかし、私たちはそのようなスタイルを取りません。私たちのスタイルはXOOPS.orgの全くの正反対にあります。

私たちの分散スタイルの利点は以下です:

1. ヒエラルキーの崩壊

幻想のヒエラルキーは打ち砕かれるでしょう。権威ある組織(コアチーム)、独占的な権威、および権威ある（と自分で考えている）人は力を失うでしょう。これらの権威が存在するかもしれないという発想は、非常にナンセンスであり、まったく不要です。公式サイトはコードと同様に小さくならなければなりません。公式とコアチームは主役ではなく、黒子にすぎません。

多くの人の行動力は、一握りの人の肩書きより重要です。この目的のために、私たちは私たちの権限をソフトランディングで放棄したいと考えています。^[1]

2. ハイスピード

誰も、自分のサイトで自分の意見、モジュール、およびドキュメントのリリースのために「議会」から認可を得る必要がありません。情報が分散していても、ウェブ2.0的な概念が複数サイトをつなげてくれるでしょう。

3. 独立

公式サイトコミュニティはXOOPS Cubeのための唯一のコミュニティではありません。 それはXOOPS Cubeコミュニティの1つです。公式サイトコミュニティとXOOPS Cubeコミュニティは等価ではありません。だれかが公式サイトを気に入らなくても、彼は彼の仲間と共にサイトを始めることができます。そして、価値観を異にする2つのサイトは新しいウェブ技術で相互理解と共に繋げられるでしょう。

このように、独立は真の相互尊重をもたらします。 XC Developers Ring を見てください。これも1つのコミュニティ・スタイルです。

4. フォア・ザ・コミュニティ

重要なスローガンは「フォア・ザ・オフィシャル」ではなく「フォア・ザ・コミュニティ」です。誰もが自分のサイトや様々なサイトで、XOOPS Cubeコミュニティに関する自分の考えを実行に移すことができます。

以上の概念は、夢物語のように思われていました。しかし、日本ではXUGJのスタートによって実現に近づき始めました。

^[1] ソフトランディングで弾力的に進めることを考えている理由は、急激な変化はしばしば混乱のトリガーとなるためです。

2人の有名なXOOPS開発者が新しいサイトを始めました。 これらのサイトは現在、利用可能であり、XC Developers Ringに追加されました。

１つはXOOPS Cube 2.1で構築された龍司さんの新しいサイトRYUSLABOです。ryuji.beにあった古いエントリーと、このサイトで公開された新しいエントリを読むことが出来ます。知りうる限り、XC 2.1によって公開を行っている唯一のサイトです。

もう１つは XC2.1 のための nobunobu さんの新しいサイトである nobunobu.com です。のぶのぶさんは、コンテンツ状況が複雑になった古いサイトから心機一転をはかるためにこのサイトを始めました。このサイトではカスタマイズのケーススタディ（いわゆるハッキング）などに関して多くのおもしろい記事が読めるようになると思います。（OSC2006/Springでそのように公言されていましたので）

XOOPS 2.0.14 JP 正式版がリリースされました。これは先週リリースされたRC1とほとんど変わりはありませんが、ひとつのバグが修正されています。これにより PHP 5.1.x でも問題なくインストールが可能になりました。

おそらく 2.0.14 は XOOPS Cube Project における 2.0.x 系の最終バージョンになるでしょう。開発チームは、しばらくの期間、重大なセキュリティ問題へのカバーを続けますが、 XOOPS JP シリーズより XOOPS Cube シリーズを推奨することになります。

XOOPS Cube 開発チームによる 2.0.x 系である XOOPS 2.0.14 JP RC1 がリリースされました。このバージョンでは大部分のNOTICE（参照に関する仕様変更によって発生するPHPの警告）がonokazuさんの頑張りで取り除かれたほか、3rdライブラリのバージョンをアップデートしています。ただ、開発チームはXOOPS Cube 2.1系に注力しているため、このバージョンのチェックは多くのユーザーの手助けを必要としています。

2.0.14 JP RC1 をインストールして、もしバグかNOTICEを見つけたら公式サイト等へ報告してください。もしRC1が大きな問題を持っていなければ、一週間後に公式リリースを行います。