色々言われているけど、やっぱり機能を追加するとき（モジュール追加）に、DocumentRoot側と、非DocumentRoot側の両方にアップロードするのは面倒くさい。
かといって、完全フロントコントローラっていうんもダサい。っていうか、やっぱURLと内容はパッと見て一致させたい。
NetCommonsみたいにフロントコントローラで使えるモードがあって、ページを指定していくのは確かに良い方法。これはユーザー目線にはページコントロールで、技術的にはフロントコントローラ。これは、Apacheのmod_rewriteが必要になる。
だが、ある意味私はApacheのmod_rewrite前提でもいいんじゃないかなっていう気もしている。
それがダメなサーバなら、カッコ悪いけど、PATH_INFOで動く方式とかな。
そうしてしまうと、TRUST_PATHっていう名前自体も意にそぐわなくなる。
プログラムは完全にTRUSTにしか置かない前提だから、XOOPS_APP_PATHとかにするんだろうな。
だけんど、XOOPS_APP_PATHの中で疑似的なDocumentRoot側のモジュールパスっていうのがあって、それはどうとでも置ける感じで。あのXOOPS2の/modules/縛りを解放したい。あぁ、解放しないと。
それができれば、あとは今のXOOPSCubeLegaｃｙの仕様でいいんじゃないかな。
もっとブロックをフレキシブルにって思ったりしたこともあったけど、それをほぼ実装したNetCommonsをちょっと弄ってみて「こんなのでWeb制作するのは大変」とか思った。分かりにくい。
やっぱ、XOOPSの分かりやすさっていうのはモジュール単位でメインとなる機能が分かれていて、それに対して補完する意味でブロックっていうのがあって、これが名称的にぴったりだったような気がする。名称大事。NetCommonsの「ルーム」という概念は変。ページだろう。
まぁ、それは私がWeb制作者の視点からNetCommonsを見てるからそう思うんであって、あれが教育の場とか学校ホームページ運営だといいのかもね。わからんけど。
