lablab.jp （日本語版）

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

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

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

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