BASE開発に関して

[K. Ono]

小野です。

コアの開発に関してなかなか議論があがってこないこともあり、先が見えない
のでネタ振りを兼ねて投稿します。

BASEとは

まずは何はともあれ、BASEの定義をはっきりとする必要があるのでは
と思います。そもそも旧来のXOOPSをLegacyとして一つのBASE（？）に
振り分けたのは、複数のBASEが開発されることを想定してのことだったと
思うのです（違っていたらすいません）。

BASEに関してminahitoさんから図を入れて何度か解説していただき、ぼんやり
と見えてきましたが、実際にBASEを開発するにはまだまだ情報不足かなーと
思います。

そこで、BASEとは具体的になんなのか、個人的な疑問点を書いてみます。

1. BASEとは、現在のLegacyにあるcore/フォルダのファイル郡（特にRoot
およびControllerあたり）を使用して、作り上げられたものがBASEなのか？

2. そうでない場合、例えばサードパーティ製のフレームワークを使用して
作り上げられたものもBASEなのか？

3. OpenPNEは次バージョンのベースとしてSymfonyで開発するそうですが、XC
でもサードパーティ製フレームワークを利用する予定はないのか？

特に気になっているのはこれくらいでしょうか。。後はこれらの回答次第
ということで。。

[Tomomichi Hayakawa]

Tomです。

Minahitoさんのレスが遅れる予感がありますので、僕の理解してる範囲でお答えいたします。
もしかしたら、理解不足、言葉足らずのところがあるかもしれませんが、
そこはどなたかがフォローしていただきますようお願いいたします。

> 1. BASEとは、現在のLegacyにあるcore/フォルダのファイル郡（特にRoot
> およびControllerあたり）を使用して、作り上げられたものがBASEなのか？

はい、そうです。
XOOPS Cube である、/core/　の上に構築された仕組みがBASEとなるはずです。

> 2. そうでない場合、例えばサードパーティ製のフレームワークを使用して
> 作り上げられたものもBASEなのか？
>
> 3. OpenPNEは次バージョンのベースとしてSymfonyで開発するそうですが、XC
> でもサードパーティ製フレームワークを利用する予定はないのか？

XOOPS Cube 側においては、サードパーティ製のフレームワークやライブラリを持つ事は無いと思います。
もし、サードパーティ製のフレームワークやライブラリが必要であれば、
BASE側でお好きなフレームワークやライブラリーなどを持つようにしていただければ良いと思います。
ですので、XOOPS Cube上に、Symfonyを使ったBASEを開発されるのもアリだと思います。

もしかしたら、誤解を招くような表現かもしれませんが、
"メタフレームワ－ク"に近いイメージではないかと思っています。

余談になってしまいますが、
OpenPNEはSymfony使うのですか！
OpenPNEの派生のMyNets は、Mapleとか。
因みに、僕の名古屋の方では、CodeIgniterが密かなブームです。
効率良くBASEを開発する為に、サードパーティ製のフレームワークを利用するのも
有効な手段かと思いますよ。

2008/06/02 12:15 K. Ono <ono...@gmail.com>:

--
味噌煮込み、手羽先 ビールに、おうえ寿司

2008/08/09 - 「OSC2008名古屋」開催！
http://www.ospn.jp/osc2008-nagoya/

[tohokuaiki]

BASEを「モジュールを動作させるために必要なもの」って考えると、
＋モジュール管理（インストーラとか）
＋ブロック管理（左右に配置させるのとか）
＋ユーザー管理（・・・微妙ですが）
＋サイト設定値（タイムゾーンとか）

だけなんじゃないかな？って気がします。
コメントとか、イメージ・マネージャとか、サイト内検索とかは
図らずもd3forum/myalbum/searchモジュールが代替として十分活用できたこと
からも、外部にやれる。


あとは、描画システム？
私はここがよく分かってないんですが、Legacyで言えば、$xoopsTplがRenderTargetで、
RenderSystemは、targetとModuleの間のレイヤーで、targetがSmartyじゃなくても
対応できるようにするため？



そう考えて、XCube_PHP4のサンプルを見ると、ControllerとRenderSystemしか無い。
というのは何となく理解できます。

サンプルがTaskっていう概念で作られているコードなんですが、多分Legacyで当てはめると
Taskっていうのが「モジュールで<{$main_contents}>を作る」処理だったり、
一つ一つのブロックを作る処理だったり、Site内検索をする処理だったりする。

じゃあ、そのTaskで処理した描画結果をどういうふうに配置するかとかは、
RenderSystem側で決める。


すると、Legacyのブロック管理というのがlegacyRenderではなくlegacyモジュールに
あるのは結構いびつな感じがします。そもそも、X2のBlock-functionの前に$xoopsTplが
作られてしまった（かつそれを利用する手法が一般化してしまった）ためにLegacyは
minahitoさんが考える描画システムを成立させるには無理な代物とならざるを得なかった
んだなという気がします。


さらに、新BASEってことは、X2の「メイン部分とブロック」っていう概念
（これはこれで素晴らしい概念だと思います。）にとらわれずに、
「ウェブサイトって何が必要なの？」
って考えた場合やっぱり「ブロックとメイン部分だけじゃないよね。」っていう
ことだと思います。
# このあたりは、他のCMSが参考になるって言うことか・・・

この辺のことをふまえつつ
[xcube-dev-ja:278] 実験用次世代テーマを公募
を読み直すとようやく何をしたいのかがちょっと分かってきた気がします。
何というか、Legacyのあのtheme.htmlに縛られすぎてた。
（逆に言うと、あれが優秀だったということの裏返しですが）


確かに、ここの構造自体を「うりゃ」ってできるとCMSになれそうな気がします。
しかし、Webサイト作る時ってヘッダとフッタ決めて、左にメニュー添えて・・・って
感じで、ある意味完全にX2の作法で作ってるからなぁ・・・・。うーん。

伊藤

[K. Ono]

小野です。

>XOOPS Cube 側においては、サードパーティ製のフレームワークやライブラリを持つ
>事は無いと思います。
>もし、サードパーティ製のフレームワークやライブラリが必要であれば、
>BASE側でお好きなフレームワークやライブラリーなどを持つようにしていただけれ
>ば良いと思います。
>ですので、XOOPS Cube上に、Symfonyを使ったBASEを開発されるのもアリだと思いま
>す。

coreのライブラリですが、CIを使用されているということでお分かりになる
かもしれませんが、フレームワークというよりも、実装アプリケーションに
近いものだと思います。例えば各種マネージャークラスが必須であったり、
ブロック関連のシーケンスが既に用意されていたり等がそれにあたります。

また、SymfonyやCIでXOOPS Cubeを作るというのは理解できますが、XOOPS Cube
下でフレームワークを使用する場合、SymfonyやCIのアプリをXOOPS Cubeの実装
に合わせなくてはならなくなるので、間に層を被せる必要が出てくるかと思い
ます。

BASE間で互換性を持たせるという理由でcoreを共通利用するというのはわかり
ますが、BASE間では互換性は一切ないということだったかと思いますので、
新規にBASEを作る場合に、本当にcoreを共通利用する必要があるのかどうかと
思います。

coreを否定しているわけではありませんが、今のところ1からBASEを実際に
作り上げるには機能不足な点が否めないので、サードパーティ製の
フレームワークやライブラリの力を借りてくる必要が出てきます。
そういった時に、OpenPNEのSymfony採用の話が出てきたり等がありましたので、
XCでは今後はどうするのかなーと。

[K. Ono]

小野です。

> BASEを「モジュールを動作させるために必要なもの」って考えると、
> ＋モジュール管理（インストーラとか）
> ＋ブロック管理（左右に配置させるのとか）
> ＋ユーザー管理（・・・微妙ですが）
> ＋サイト設定値（タイムゾーンとか）

僕が１から作るとするとモジュール開発側やテーマ開発側のどっちから見ても
少し問題がありすぎると思うので、ブロック管理は捨てますね。。

コンテンツが最終的にどのように表示されるかに関しては、モジュール開発者
ではなくできるだけテーマ開発者が決められるようにするべきだと思っています。
もちろん、今のXCLのように各ブロックがHTMLを返すのではなくて
配列やXML等を返したりするのであれば少しは良いのかもしれませんが。

利用可能なブロックをコア側で決めてしまって（最新情報ブロック、メニューブロック等）、
XCLの検索のような感じでモジュール側がそれに対応するというような感じでも
良いんじゃないかなーと思います。テーマ側も、表示されるブロックが限定される
のでより柔軟にブロックのコンテンツを配置できるし、Vicuna CMS等との
連携も容易になると思います。

テーマ開発側から見るとPHPNuke時代に逆戻りのような感じもしますが。。

[ITOH Takashi]

伊藤です

K. Ono さんは書きました:

> 小野です。
>
>> BASEを「モジュールを動作させるために必要なもの」って考えると、
>> ＋モジュール管理（インストーラとか）
>> ＋ブロック管理（左右に配置させるのとか）
>> ＋ユーザー管理（・・・微妙ですが）
>> ＋サイト設定値（タイムゾーンとか）
>
> 僕が１から作るとするとモジュール開発側やテーマ開発側のどっちから見ても
> 少し問題がありすぎると思うので、ブロック管理は捨てますね。。

それは確かにそうなんですが、ユーザー視点から見ると、
ブロックっていう概念てすごくわかりやすいというか、
サイトを構築する上でとっかかりになるものだと思うんですよね。

Web制作屋の視点で、XOOPSのブロックを見ると
「なんだか、使いにくいなぁ・・・」
「使うブロックとその場所は固定する」
という感じになっちゃうんですが、それはそもそも全体のサイトマップが見えているから
なんですよね。普通にホームページ作るのにXOOPS使う人って
あーでもないこーでもないって試行錯誤しながら決めていくと思うんです。

最近、私がXOOPSを評価するときに最初に来るのが、
「ある程度ホームページを作るのに道筋をつけてやった」っていうところです。
MTをはじめとするブログ系や、Wikiなんかのコンテンツ系って
「さぁどうぞ！」って言われても困るんですよね。ModxとかDrupalもそんな感じだったかな。
「何すればいいの？」感漂う。ブログはその点、日記書くっていう道があるから
すぐできますが。
# しかし、最初に「MTでホームページ作る」とか聞いた時は
# 「何を言っているのだ？」という気になりました。しかし、結構良いのができたりする

まぁ、そもそも「何すればいいの？」って人がWeb立ち上げるなよって話かもしれないんですが、
それは立ち上げ方を知らないだけで、立ち上げたいって思ったからには何かしら
コンテンツになるものがあって、そこにプロの制作屋が入れば何かしら作れたり
しますし。（というか、作りますし）

そういう意味で、X2の標準モジュールってユーザーがホームページを
構成する上で必要最小限的な感じがあってよかったなと。

> コンテンツが最終的にどのように表示されるかに関しては、モジュール開発者
> ではなくできるだけテーマ開発者が決められるようにするべきだと思っています。
> もちろん、今のXCLのように各ブロックがHTMLを返すのではなくて
> 配列やXML等を返したりするのであれば少しは良いのかもしれませんが。

この辺になっちゃうと、完全に「プロ仕様」のXOOPSですよね。

伊藤

[minahito]

minahito です。
すみません、返信したつもりでいたのですが、メールが
送信できていなかったらしく gmail 上で下書き扱いになってました。(ToT)

以下返信です。

> 1. BASEとは、現在のLegacyにあるcore/フォルダのファイル郡（特にRoot
> およびControllerあたり）を使用して、作り上げられたものがBASEなのか？

ということになります。
将来的に site_config.ini.php の管理と連動したダウンロードクライアントを
開発したとき、そのツールを使って組み合わせを変えるアッセンブリに対応
したパーツが BASE です。

BASE の意味合いは 0.9 では Controller を実装するもの、でしたが、
1.0 では「初期のタスクを生成するもの」に変化しています。
（サンプル参照）

> 2. そうでない場合、例えばサードパーティ製のフレームワークを使用して
> 作り上げられたものもBASEなのか？

別途フレームワークを使用しても、交換部が対応していれば BASE になりま
す。

> 3. OpenPNEは次バージョンのベースとしてSymfonyで開発するそうですが、XC
> でもサードパーティ製フレームワークを利用する予定はないのか？

XC コア側で特定のフレームワークを採用する予定はありません。

> coreを否定しているわけではありませんが、今のところ1からBASEを実際に
> 作り上げるには機能不足な点が否めないので、サードパーティ製の
> フレームワークやライブラリの力を借りてくる必要が出てきます。
> そういった時に、OpenPNEのSymfony採用の話が出てきたり等がありましたので、
> XCでは今後はどうするのかなーと。

えーと、
提示されているビジョンの資料が説明力不足なこともありますが、コア（プ
ラットフォーム）に望まれるものと、ＳＤＫに望まれるものが若干混ざって
いるのかなと思います。

XOOPS Cube コアのスタンスはプラットフォームであり、プラットフォーム
は土台であって、生産性を促進する仕組みではありません。 core には BASE
のあり方を規定する土台の仕組みは必要ですが、生産性を助ける必要はないと
いうのがスタンスです。

たとえば XOOPS2 にも、プログラム開発の生産性を高める仕組みは一切あり
ませんでした。したがってプログラムを作る側としては「別にXOOPS2を利
用する必要はない」でしたが、一部分を作れば済む点、コミュニティで共有
できる点（拡張・改変版が登場する楽しみ）が魅力でした。

これは１プロダクト書き下ろしでは持ち得ない、フリーソフトウェアならでは
の魅力です。ホリデープログラマを引き付けてならないのもこの点でしょう。

同様に、 BASE などの可換パーツの開発者も、可換パーツのひとつでも作れば
済む点、コミュニティで共有できる点（拡張・改変版が登場する楽しみ）が魅
力になってくるという考えで、 XOOPS Cube コアの設計があります。

XOOPS Cube もいま具体的な説明ができるほど、プログラムが溜まっていませ
んので、例によって OGRE を挙げます。

OGRE には、各種シーンマネジメント、各種レンダーシステム、物理演算、
ＡＩ（人工知能）などのプラグインが存在し、コンフィグファイルの指定で
コア経由でロードされ、メモリにオンステージします。

プラグインが全くない状態では起動できません。
（厳密に言うと、起動はできるが、３Ｄエンジンとしては動作しない）

ではプラグインを開発するための（３Ｄレンダリング、物理学、ＡＩのため
の）生産性を高めるようなフレームワークがコアに搭載されているのかとい
うと、一切搭載されてません。

搭載しようがないんですけど(^^;
意義からいってもまったく不要。

つまり考え方によっては、「OGREコアを使う意味はない」「メリットはな
い」のです。

たとえば今は Windows 系の最新技術である DirectX 10 に関するレンダーシ
ステムは試作版がありますが、少し前までは DirectX 10 レンダリングを試
すには、わざわざ OGRE の形式に合わせて動的ライブラリを書かなければ駄
目でした。

それではなぜ人は面倒な思いをしてまでOGREコアの上でプログラムを書く
ことに魅力を感じるかというと、

1. 弄ってて、不足を感じたので可換部の一部を書き始めた
2. 弄ってて、変えたくなったので変えて、ついでに頒布した
3. コミュニティに技術者が多いので、力試しに作って配ってみた
4. 新技術が出て来たので OGRE 適用版を作ってみた

というあたりなのではないかと思います。

もちろん、こんなもの使わないという人もいますし、機能が一通りそろって
いる（その代わり内部の交換が極めて困難な）エンジンを好む人もいます。

OGRE も発想が受け入れられ、いろんな人がいろんなものをOGRE コアと
いうプラットフォーム上で作業するようになって、活発な現況に至るまで、
数年かかりました。僕も序盤はかなり疑いの目で見てました。

OGRE は、偶然か、戦略的にか、最初から UnrealEngine や Valve Source
といった商用製品に対抗するのではなく、オープンソースで多人数で作って
使うエンジンを作るなら、こういう設計がベストだ、という「オープンソー
スの特有さ」に目を向けて作っていたように思います。

XOOPS Cube の起動シーケンスも一時期 DICON ライクと表現された時期も
ありましたが、 DICON はソフトウェア開発にとって生産的なメリットのあ
る仕組み。 OGRE と Cube の起動シーケンスはフリーソフトウェア開発の
「形態」にメリットのある仕組みだと思っています。

これを"通例"のソフトウェアデザインで解釈することは難しいのですが、幸
いにも"通例"を片手に仕事をしているような Web プログラムの専門家は Cube
では多くありません。

たとえば僕も、Web開発業務の"セオリー"と言われるものを本で読むことは
出来ますが、そのセオリーを実践して経験として自分のものにすることはで
きません。

OGRE の言わんとすることは、他のコミュニティでは無理でも、XOOPS Cube
コミュニティなら伝わると思っています。

繰り返しになりますが、可換パーツの生産性を助ける仕組みはOGREコアには
ありません。OGREコアにあるのは可換パーツを"可換たらしめる仕組み"です。

そこに意義を見いだすか、
それとも「メリットはない。コアを使う必要はない」と判断するかは開発者個
人個人の考え方によるでしょう。

実際、 OGRE のやり方をナンセンスだと考える人も今でも非常に多いです。
プログラム的にはベストな設計ではないですからね。
このへんは2005年末にもたっぷり話したことなのでもういいとは思いますが……
まぁ、我々としては OGRE と同じ方式を採ったということですね。(^^)

当然、余計な作業はそこかしこに発生しますが、
XOOPS Cube コミュの開発者はシビアではない（ガリガリしてない）ので、そ
のへんで損得を云々する人はいないかなと。

# そもそも Nuke 自体が
# モジュールによるコンストラクションを可能にする設計に同意してプログラム
# するものだから、通常のプログラムより明らかに手間なので。

> BASE間で互換性を持たせるという理由でcoreを共通利用するというのはわかり
> ますが、BASE間では互換性は一切ないということだったかと思いますので、

互換性が一切ないということはありません。
まったく同様の会話を以前しましたが;;

そのために突っ込んで検証中なのがタスクシステムや汎用レンダーシーケンスです。

タスクシステムは以前のガンダーラビデオにあったように、ＰＣの巡回システム
（ランタイムシステム）がプログラムパーツのアプリケーション間流用を促進す
るという近年の考えにのっとったもの。

汎用レンダーシーケンスは、レンダーシステムの使い方をコアレベルで規定し、
同じくプログラムパーツのアプリケーション間流用を高める仕組みです。
（これがないとタスクシステムでプログラムを流用しても画面出力がつながらず、
マルチBASE対応が難しい）

プログラムレベルでは、これである程度互換性が取れると思います。 CMS が認
識するモジュールの形式はバラバラなのでそこは追加作業はあると思います。

たとえばシンフォニーフレームワークを使っているからといっても、OpenPNE
のモジュールを他のシンフォニーフレームワークを使っているプログラムにその
ままインストールすることはできないと思います。

詳しくないですが、そのままは無理なはずです。

シンフォニーはプログラムの進行の仕組みを提供しますが、「なにをもって母体
のモジュールとするか」という認識単位まで定義していないはずです。

したがって、「移植は比較的容易だが、そのままでは使えない」という状態になっ
ているのではないでしょうか。

Cube もクロス(BASE)プラットフォームは無理だが、マルチプラットフォームなら
可能という感じに……そういう場合のプログラミングのコツは、どのジャンルであ
れ定番のやり方があるので、またそういう状況になってきたら話が出せればと思い
ます。

個人的には、マルチ対応とかは、「ひと手間」というよりは、
その「ひと手間」をするのが、プログラマのミッションなんだ！とは思ってます。

とりあえずオフィシャルウェブサイト周りを片付けたら、
サンプル BASE の開発に復帰する予定です。(^^;

2008/06/03 17:28 K. Ono <ono...@gmail.com>:

--
minahito (mina...@gmail.com)

[K. Ono]

onokazuです。

詳細ありがとうございます。

簡単に言うと、コアは使う必要があると思えば使って、必要がないと
思えば使わなくて良いということですね。X2のようなスタンスであるとは
思っておりませんでしたので、少し意外でした。

>同様に、 BASE などの可換パーツの開発者も、可換パーツのひとつでも作れば
>済む点、コミュニティで共有できる点（拡張・改変版が登場する楽しみ）が魅
>力になってくるという考えで、 XOOPS Cube コアの設計があります。

うーん、そうですか。。
ただ、通常、フレームワークと呼ばれるものは、この交換可能性・拡張性を
考慮して作られているものだと思いますなので、交換可能性がXOOPS Cubeコア
の魅力であるというのは、開発側からすると少し弱いかもしれませんね。。
どうしてもXOOPS Cubeという環境上でしか動作しない「サブシステム」の
開発が必要な時に作る。。そんな感じでしょうか。そのためには新BASE
の早急な普及が望まれますね！

[K. Ono]

onokazuです。

>Web制作屋の視点で、XOOPSのブロックを見ると
>「なんだか、使いにくいなぁ・・・」
>「使うブロックとその場所は固定する」
>という感じになっちゃうんですが、それはそもそも全体のサイトマップが見えてい
>るから
>なんですよね。普通にホームページ作るのにXOOPS使う人って
>あーでもないこーでもないって試行錯誤しながら決めていくと思うんです。

うーん、確かにそれもありますね。。

個人的には、素人には真似できないほど格好よく表示さえしてくれれば、
ブロックの位置や表示方法はテーマ作成者にお任せします！という感じ
なんですが^^;

ブロックの有効化・無効化の切り替えと、表示するデータの件数等の
最低限の設定さえあれば十分かなとか思ってしまっています。

すいません、先の投稿で「ブロック管理は捨て」と書きましたが、最低限の
設定はあるが、今のように管理者やモジュール開発者が自由にブロックを
追加したり配置するような機能を省くという意味でした。

BASE側も軽量化できそうですし、そんなLegacyの軽量版みたいなものが
あっても面白そうですね。

[minahito]

minahito です。

>>同様に、 BASE などの可換パーツの開発者も、可換パーツのひとつでも作れば
>>済む点、コミュニティで共有できる点（拡張・改変版が登場する楽しみ）が魅
>>力になってくるという考えで、 XOOPS Cube コアの設計があります。
>
> うーん、そうですか。。
> ただ、通常、フレームワークと呼ばれるものは、この交換可能性・拡張性を
> 考慮して作られているものだと思いますなので、交換可能性がXOOPS Cubeコア
> の魅力であるというのは、開発側からすると少し弱いかもしれませんね。。

これなんですが、本当にそうなんでしょうか？
いや、実は前々から、
一般的なフレームワークが推奨するプログラミングは、プログラマレベルでの交換・
拡張性は確保されていますが、モジュールを入れ替えるだけでプログラムの結合イメー
ジが変更され、それでもそのまま動作するような Nuke 的なモジュール式とは違う
のではないかと感じているんです。

モジュールを出したり入れたりするだけでそのまま動くように設計されているプロ
グラムのほうが「異常」で、大多数のプログラマは特別な事情が無い限り Nuke の
ような課題にはトライしないんじゃないでしょうか。

onokazu さんの仰る一般的に「交換・拡張性を考慮して作られているフレームワー
ク」というのは、僕らが会社で仕事で触るようなプログラム……

「プログラマが交換・拡張しやすいようなソースコードになっているプログラム」
「実際にその作業をするときはどうぞ再コンパイルしてくださいというフレームワーク」

であって、 XOOPS シリーズのような、
全部ダイナミックリンク的な発想で作られていて、
モジュールの入ったディレクトリをマウスでぐりぐりやったり、
設定ファイルを書くだけで、
あとは少々シンボリックエラーのある関係でも中間層がフェータル化を防ぎ、
かつ連携する
（XCubeでプリロードを導入した事で何とかこのへんはプログラマ寄りの挙動になりましたけど）

といったアーキテクチャを考慮したフレームワークは無いんじゃないでしょうか。

だって開発者が Nuke のように特別なエンドユーザー・エクスペリエンスを提供する
ことを目的としない限り、そんな苦労をする理由が開発者側にないと思うし、フレー
ムワークがその苦労を考慮する必要も無いと思うんですよ。

だから onokazu さんのいう
「通常、フレームワークと呼ばれるものは、この交換可能性・拡張性を考慮して作られている」
と、
僕のいう（というか OGRE が提唱した）
「交換可能性・拡張性」
は、言葉こそ同じであれ、全然別の話ではないかと思うんですよ。

ぐわああ、
あと一息のような気がするんですが、うまく擦り合わせができない。

なんというか、
スクラッチモデルを作れるモデラーが一般のプログラマなら、
そういうスクラッチモデルを拡張したり、部分交換できるように提唱されているのが
onokazu さんが例に挙げたフレームワーク。
（開発フレームワークと呼ぶべきか）

で、僕らが言っている交換・拡張性というのは、
ガンプラみたいなもので、ポイントはユニバーサルジョイントを使用して、
ガンダムの腕を外してザクの腕をつけてすぐポーズをつけて遊べるような
ユーザー体験のための交換・拡張性ではないでしょうか。

もちろん開発者もユーザーに含む。

で、ここでいう開発者のメリットというのは、
「たかが既製品だと思ったら腕が外れる」
だと思うんです。

だから XOOPS Cube のいう交換・拡張性とは、
それはスクラッチ系をいじる開発者に対して言える魅力ではなく、
既製品を弄って、既製品を弄るコミュニティのなかで俺カスタムや俺パーツを出す
楽しみに対する魅力だと思うんです。

# XOOPS Cube の場合はボディ(BASE)も交換できる感じ？
# XOOPS Cube コアは内部の５肢を定めるフレームワーク。
# だからジオングは作れませんとか……

……やってしまった……また訳の分からん例えを…… orz

無茶を承知で続けますが、
昔、バンダイのプラモデルで "Vフレーム" というのがあったんですよ...
1/144 スケールの "Vフレーム" というPE製のフレームがあって、これが
スケルトンのように内部構造の人体性を保証して、
ロボットの各パーツはこの V フレームを包む形で接着してたわけです。
で、 Vフレームを採用しているプラモデルだと手足が交換できたり、
武器が流用できたりしたわけですよ。
（それを堂々とパッケージに書いて世の少年たちに新しい遊びだと訴求していた）

まぁこんな感じで……
http://www.doublenuts.com/v.html

フルスクラッチだろうが、パーツが外れるプラモデルを例えに出した時点で
すでに正しくない気もしますが;;

たとえば仕事とか、プラモデルの賞を取ろうとする開発者（モデラー）は
こういうのには手を出さないと思うんですよね。

でももし手を出す人がいれば、それは別の目的があると思うんですよ、
「自分で自分の持ち物に手を加える」とか
「それを配る」とか
「エンドユーザーが多いからこそ、そのフィールドで作る」とか。

そーいう人に対して、手足が溶着してないもの、
それどころか V フレームさえ守れば部分的にスクラッチなものを作って
（あるいは既製品を弄って）使えること、といった部分を担保するのが
XOOPS Cube や OGRE の言っている「交換性」なんだろうと思います。

で、世間でいう開発フレームワークは Vフレームなのかというと、
それは違うんじゃないかと思うわけです。

# 僕自身はそういうのを触る人と、
# こういう開発者自身もコミュニティでワイワイやるための土台を触る人と
# いうのは交わらないと思ってます。
# だから、前者な人に訴求するコアではない。
# 後者の人により訴求するコアであれば良いのかと。

すみません奇跡的に理解できた人フォローしてください。;;;

> どうしてもXOOPS Cubeという環境上でしか動作しない「サブシステム」の
> 開発が必要な時に作る。。そんな感じでしょうか。

イメージ的には、
「俺的XOOPS」を作らなくても BASE などを弄れる、
「レンダリングがおかしいと思う！」というときにレンダーシステムを書く、
「俺は全然違うものをコミュニティに提案してやるぜ！」というときに BASE を
スクラッチする、とかそんな感じです (^^;

うーん、うまく言えない？？

# なんとなく伝わってますよね?? (^^;

--
minahito (mina...@gmail.com)

[tohokuaiki]

伊藤です。

Vフレームの画像、探しました。衝撃でした。
http://blog.tosounds.dyndns.org/blog/to_hobbys/img/JVLN0007.JPG

私自身、既製のフレームワークを使ってXCLのディストリに参加していますが、
色々と気を付けないと行けないことが出てきます。

その全てはやはり「交換可能」っていうところです。簡単にいうと「お互いに
何やってるか分からない」というところに根ざします。
たとえば、
・UrlHandlingを独自に.htaccessで変えてしまっていると、他のF.W.と共存できない
・error handling/log handlingは勝手に定義してはいけないが、F.W.は大抵自前の
　それらを前提にしている
・Magic Quotesの戻しなど、GPCに関するものは勝手に処理してはいけない。
　他のモジュール（ないしBASE）ではそれらが各々処理する*かも*しれない。
・ネームスペース（もどき）の考慮。特にCakePHPなんかは結構汎用性の高い名称で
　Classを定義してるので危険。

Symfonyなんかは、完全に1サーバを自前で使えること前提だったりするので、
(なので格安レンタルサーバではキツイ・・・らしいです。)
同一のPlatformの上で複数F.W.を使うっていうのは現実的には難しいのかなぁと。
もちろん、F.W.に手を入れればいけるでしょうが。

なので、
・XCubeは、マルチF.W.でも動くことを考えています。
・でも、現存のPHPフレームワークを複数使うのって現実的じゃないよね。

その辺の食い違いがminahitoさんとOnoさんの「あれ？」っていうところなのかなぁ・・・
と思ったり。

ただこのあたりは、OnoさんのSabaiとかminahitoさんのexFrame(今はLegacy_Frame?)
だと既に他のF.W.と共存を前提にしたり、「他のものに影響を与えないように」と
考えながら作られていると思うので、若干ほかの既製PHPフレームワークとは事情が
違うかなぁと感じます。

個人的には、Symfony/CakePHPみたいなscaffoldで楽々開発～みたいな重量級なのは、
XCube的にあまり相性が良くなくて、EthnaやMapleなんかの軽量級はいいんじゃないかなと
思ってます。特に、Mapleは「他のクラスに依存しない」っていう考えで作ってるらしい
（私は実際には使ったこと無いので受け売り文句）ので相性がいいんじゃないかなと
思います。（開発完全に止まってますが）

> たとえば仕事とか、プラモデルの賞を取ろうとする開発者（モデラー）は
> こういうのには手を出さないと思うんですよね。
>
> でももし手を出す人がいれば、それは別の目的があると思うんですよ、
> 「自分で自分の持ち物に手を加える」とか
> 「それを配る」とか
> 「エンドユーザーが多いからこそ、そのフィールドで作る」とか。

私がちょっと不安に思ってるのが、実は既存のXOOPSモジュール開発者って、
「使ってもらってなんぼ」
「俺が使いたいから作る」
ってスタンスで、ちょっといわゆる開発開発っていうのとは情熱のベクトルが
違うんじゃないかなぁという点です。

もちろん、新しい人が「あれ、これ面白いんじゃないの？」って入ってくることを
すごい期待するんですが。ですが、PHPの人って
「プログラムの技術的に面白くってトライして（イメージ的にはてな村の人）、
　かつエンドユーザーがポン付けで使えるものを出す（イメージ的にXOOPSの人）」って
日本人があまり見当たらない気がします。

> # 僕自身はそういうのを触る人と、
> # こういう開発者自身もコミュニティでワイワイやるための土台を触る人と
> # いうのは交わらないと思ってます。
> # だから、前者な人に訴求するコアではない。
> # 後者の人により訴求するコアであれば良いのかと。

すみません、このパラグラフの前者／後者が何をさしているのかよくわからなかったです。

伊藤

[K. Ono]

onokazuです。

話をややこしくしてしまってすいません。

僕が言おうとしていたのは、
XOOPS Cubeというものを全く知らない開発者が、何もない状態からCMSアプリを
作ろうと思った時に、XOOPS Cubeを使えば交換可能性や拡張性が約束されるので
XOOPS CubeプロジェクトでCMSを作るべきだというのは魅力として弱いのではないかな
ということを言いたかっただけです。

そういう意味では

> onokazu さんの仰る一般的に「交換・拡張性を考慮して作られているフレームワー
> ク」というのは、僕らが会社で仕事で触るようなプログラム……

>「プログラマが交換・拡張しやすいようなソースコードになっているプログラム」
>「実際にその作業をするときはどうぞ再コンパイルしてくださいというフレームワーク」

ということになりますね。。

もちろん、XOOPS CubeプロジェクトでCMSを作る魅力がないと言っているわけでは
ありません^^;

すいません、なんでこんな流れになったのか自分でも分かりません。^^;
BASE開発の話から、CMSをゼロから作り上げたりフレームワークの話に
なってしまったからでしょうか。