PEAK XOOPS - モジュールの多態性

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/内に置かれた各モジュールが、サブクラスに相当します。

実は、この多態性を実現する上で、未解決の問題があります。

例えば、tinyd0において、言語定数を書き換えたとしましょう。この場合、tinyd0のメインページにおいて、tinyd0しか読み込まれていなければ、期待通りに動作します。しかし、もしtinyd0とtinyd1をブロックとして読み込んでいる場合、おそらく期待通りにはなりません。同じ定数名を利用しているのですから、両方とも同じ文字列が表示されてしまうことになってしまうのです。

このあたり、どうするべきか検討中ですが、もはや「言語定数」から脱却すべき時期が来ているのかもしれません。モジュールインスタンス毎に言語オブジェクトを作って、管理画面からの編集も可能とする。そして、言語オブジェクトそのものは、Smartyにオブジェクトとしてアサイン……と、できたら良いのですが、それだとCube専用モジュールになってしまうので、現時点では却下ですね

いずれにせよ、コアが直接取り扱うmodinfo.phpについては、こんな構造にするしかないですかね。

$language_constants = array(
	'MYNAME' => 'wrap' ,
	'MODULEDESC' => 'ページラップ専用モジュール' ,
) ;
foreach( $language_constants as $key => $val ) {
	define( '_MI_'.strtoupper($mydirname).'_'.$key , $val ) ;
}