PEAK XOOPS - News

システムモジュールは、XOOPS 2.0/2.2では、外すことのできないモジュールです。
そしてシステムモジュールの使いづらさは、XOOPSユーザの長年のストレスでもありました。
特に、ブロック管理・グループ管理・テンプレート管理の使いづらさは特筆すべきレベルであり、それを打ち破ってきたのが、myblocksadminであり、mymenuであり、mytplsadminである、という自負が私にはあります。

そして今日ここで新たにaltsysモジュール＆ライブラリのリリースを発表できることを誇りに思っています。

myblocksadminやmytplsadminの弱点はこのようなものです。

- 各モジュールがファイル実体を持つため、メンテナンスが大変
- Duplicatable V3 のような実装にそぐわない
- XoopsCubeで予定されているsystemモジュールの換装に耐えられない

そこで、XOOPS_TRUST_PATHを利用する形で大きく書き直したのがaltsysです。機能的にはこのようになります。

altsys = myblocksadmin + mytplsadmin + mymenu + alpha

「プラスアルファ」ってことで、アルファ版からのリリースです。

altsysは、ライブラリでありモジュールであります。このあたりは、myblocksadminなどと似ていますが、実体のほとんどは、XOOPS_TRUST_PATH内に存在し、ファイルとしての重複がないことに違いがあります。

Duplicatable V3では、そのmymenuに仕掛けがあり、XOOPS_TRUST_PATH/libs/altsysを見つけ次第、ブロック管理やテンプレート管理といったメニューを追加します。先行してリリースしたD3モジュールの第１弾wrapsにも、もちろんこの仕掛けが仕込んであります。

これで私にとっての大きな障害はなくなりました。

D3モジュールを次々とリリースしていくだけです！

ここ連日、Duplicatable V3について書いてきましたが、そのモジュール第１弾として、WRAPSモジュールをリリースしました。

http://www.peak.ne.jp/xoops/md/mydownloads/singlefile.php?lid=75

これはページラップ専用モジュールで、XOOPS_TRUST_PATH内のwrapsディレクトリ以下のファイルをラップします。

拡張子.htmlおよび.htmのファイルについてのみ、XOOPSヘッダとXOOPSフッタをつけて出力し、それ以外のファイルについては、適切なContent-Typeと共に送出します。これらページラップ化されたファイルはすべて、モジュールアクセス権限の影響を受けるため、グループ毎のアクセスコントロールが可能です。

古くからのXOOPSユーザであればピンと来たかもしれませんが、要するにAuthと同じ動作です。（ただしコードは１行たりとも参考にしていません）

もちろん、D3モジュールならではのギミックもそこかしこにちりばめてあります。XOOPSモジュールを作ったことのある人であれば、ソースコードを見てニヤリとすること請け合いです。（動的生成アイコンとか、PATH_INFOの取得方法とか）

モジュール用ライブラリとして提供しているmymenuですが、これをDuplicatable V3モジュールに実装するにあたり、機能を２分割することにしました。

(1) メニュー定義ファイルを読み込んで管理画面上部に表示する (純 mymenu)
(2) モジュールの一般設定操作性の向上 (仮称 mypreferences)

冷静に考えてみれば、(1)と(2)は似ても似つかない機能であり、分割することでスッキリしたなあ、という印象です。

(1)は、各モジュールがXOOPS_TRUST_PATH内に持ちます。そして、必要に応じて、メニュー定義の後ろに、myblocksadminやmytplsadminへのリンクを表示するようにします。もちろん、一般設定があれば、(2)へのリンクも表示します。

mypreferencesは、XOOPS_TRUST_PATH内のライブラリとします。

- mypreferences
- mytplsadmin
- myblocksadmin

これらの３大機能は、altsys (Alternative System Library)としてリリースする予定です。
この実体の置き場は、

XOOPS_TRUST_PATH/libs/altsys/ とする予定です。

Duplicatable V2.1モジュールの不満点は、実はもう一つだけあります。

それは、せっかく「複製可能」であるのに、各モジュールインスタンスの動作に多態性を持たせることが出来ない、ということです。

もしあるモジュールインスタンスに多態性を持たせたとしても、モジュールアップデートで書き潰されてしまうからです。

その点、Duplicatable V3であれば、多態性を持たせるのは比較的簡単です。というのも、XOOPS_ROOT_PATH/modules/ディレクトリという、最初にアクセスされるべきファイル群はすべて、単なるフックとなっているからです。


サイト毎にカスタマイズ可能を謳うOSSアプリケーションでは、フック処理が良く利用されます。ある特定のファイルを作ると、そちらに動作が移行するというタイプで、ZenCartなどが有名でしょう。

ただ、このタイプだと、どこでフックをしているのか、調べないと判りません。さらに、本体のアップデートでフック処理が置き換わってしまう可能性もあります。（私自身、ZenCartのアップデートで何度もハマったことがあります）

しかし、Duplicatable V3のフックはそれとは逆です。ロジック本体こそが、フック内にあるのです。XOOPSの動作さえ知っていれば、各モジュールについての処理が、XOOPS_ROOT_PATH/modules/に来ることは判っているはずです。そして、それらのファイルこそ、ユーザが書き換えて良いファイルなのです。そのフック処理をやめてしまえば、完全に自分でコントロールできますし、ちょっとだけ処理してからデフォルトのフックをかけることもできます。

これはまさにOOPで言うところの多態性です。XOOPS_TRUST_PATH/modules/内に置いたファイル群が親クラスで、XOOPS_ROOT_PATH/modules/内に置かれた各モジュールが、サブクラスに相当します。

説明の順番が前後してしまいましたが、Duplicatable V3の前提に、XOOPS_TRUST_PATHという重要な概念があります。

XOOPS_TRUST_PATH とは、PHP定数です。XOOPSをある程度触った方ならご存じのXOOPS_ROOT_PATH の親戚のようなものです。この定数は、mainfile.phpで定義します。

define('XOOPS_TRUST_PATH','/home/yourhome/xoops_trust_path');