ホーム > フォーラム > 質問箱 > XC 2.1 と system モジュール

XC 2.1 と system モジュール
投稿者: ohwada | 投稿日時: 2007/5/14 20:45 | 閲覧: 11866回
ohwada
XC 2.1.0 リリースおめでとうございます。
遅ればせながら、試しはじめました。

1つ質問です。
system モジュールが extra に入っていますね。
system モジュールは非標準ということですか。

スナップショット版では、modules 配下に入っているので、
system モジュールの扱いは気にしていなかったぞ。
http://xoops.sourceforge.jp/snapshot/

今回、クリーン・インストールしたら、system モジュール絡みのエラーが出た。
ビックリしたのは、私だけ?

docs に何か書いているかと思ったが、
コアのライセンスに「修正BSD」を採用したことしか、分からなかった。

xoops 2.0系のモジュールは 「一般設定」(preferences)などで system モジュールを必要とするという認識なのですが。
互換リストを見ると、「System Required」でなく、「Compatibilty OK」になっていますね。
http://xoopscube.org/modules/pukiwiki/index.php?XOOPSCubeLegacy%2FModuleCompatibility

う〜ん、何か勘違いしている


ついでに、もうひとつ。
docs/CHANGERS.txt が 2.0.12 JP で止まっていますよ。

コメント(10)

新しいものから | 古いものから | ネスト表示 | RSS feed
Re: XC 2.1 と system モジュール 
投稿者: ohwada | 投稿日時: 2007/5/15 21:06
ohwada
勘違いに気づきました。
「一般設定」へのリンクは xoops_version.php から コア側で生成しているんでしたね。

私の作成したモジュールでは、独自にメニューを作ってました。
その際、「一般設定」へのリンクは
/modules/system/admin.php?fct=preferences&op=showmod&mod=xxx
という形式で system モジュールを呼んでました。
うまくいかなかったのは、この部分でした。

さて、system モジュールなしでも動作するように、変更せねば。
Re: XC 2.1 と system モジュール 
投稿者: ohwada | 投稿日時: 2007/5/18 19:20
ohwada
「一般設定」へのリンクですが。

XOOPS/modules/system/admin.php?fct=preferences&op=showmod&mod=xxx

の代わりに

XOOPS/modules/legacy/admin/index.php?action=PreferenceEdit&confmod_id=xxx

とすれば、いいですか。
それとも、別の作法がありますか。
Re: XC 2.1 と system モジュール 
投稿者: minahito | 投稿日時: 2007/5/19 12:34
minahito
ぐわっトピック見落としてた
す、すみません...


$root =& XCube_Root::getSingleton();
$root->mController->getPreferenceEditUrl($xoopsModule);


で得ることができます。


しかし、よく考えると Legacy_Module クラスじゃなくて XoopsModule クラスを引数にとるのは変っすね...
(というか Legacy_Module が積めばいい気もしてきたが...)
Re: XC 2.1 と system モジュール 
投稿者: ohwada | 投稿日時: 2007/5/20 17:03
ohwada

$root =& XCube_Root::getSingleton();
$root->mController->getPreferenceEditUrl($xoopsModule);


これで取得しているのは、


XOOPS/modules/legacy/admin/index.php?action=PreferenceEdit&confmod_id=xxx


ですね。
直接、後者を記述しても、今のところは問題ないのかな。

コアに問い合わせて、特定のモジュール(legacy)が返ってくるのは、奇異な感じがする。
将来的に、legacyが無くなると、別のものが返ってくるのだろうか。
Re: XC 2.1 と system モジュール 
投稿者: tadashi | 投稿日時: 2007/5/20 17:51
tadashi
引用:

しかし、よく考えると Legacy_Module クラスじゃなくて XoopsModule クラスを引数にとるのは変っすね...
(というか Legacy_Module が積めばいい気もしてきたが...)


分離ははっきりしほうが、いいですね。
コアは、ある意味 XOOPS とは無関係になりますから、
というかそうなると、halt さんがいっているように、すごいことになるかもですね。

Legacy なしの開発用base(機能が貧弱でないといけませんが、)がでてくるといっきにかわるような気がします。


Re: XC 2.1 と system モジュール 
投稿者: minahito | 投稿日時: 2007/5/21 12:52
minahito
# えらい長文になってしまった...!

引用:
コアに問い合わせて、特定のモジュール(legacy)が返ってくるのは、奇異な感じがする。
将来的に、legacyが無くなると、別のものが返ってくるのだろうか。


このへんがどうなっているか...
直指定を避けなければならない想定(派生base)はどういうものかというと...

XOOPS2 JP のモジュールはすべて Legacy 専用モジュールになります。これらのモジュールからみた場合 Legacy は Base モジュールという従前のコアに相当する(setting_*.iniによって構築される環境の)中核になりますから、

引用:
コアに問い合わせて、特定のモジュール(legacy)が返ってくるのは、奇異な感じがする。


以上のことから、ここでモジュールが(baseである) Legacy 独自のインターフェイスを知っていることは特に問題ないという感じです。

(XCubeコア自体は CMS の具体的実装には関与しませんから、モジュールは、なにかの Base のモジュールであって XCube のモジュールではないということになります。そして特定の base に依存性を持っています)

決め打ちを避け、メソッドを通じなくてはいけないのは、 Legacy のインターフェイスを持つ別の base (想定されるのは小改造版)に対して、このインターフェイスを通じてプリファレンスに誘導してもらうことを想定しているためです。それはユーザーがどのようなセッティング・チューニングセットアップを行うかによりますので、現時点でモジュール側は base が Legacy 派生系で交換される可能性に配慮をしておく必要があります。

しかし、全く異なる仕様をもった base と組み合わせる場合は、

- プリファレンスといった仕様をもっているか
- 誘導する URL があるのか
- いや……そもそもモジュール自体、起動できるのか
(Legacy 専用モジュールを動かせるのか)

ということは保証されません。

したがってLegacy用モジュール側は、自分が依存している Legacy の独自のインターフェイスにどんどんアクセスして構わなくて、依存外の base と組み合わされる可能性までは検討しなくていい。ファミコンのソフトが、「いま、俺を実行しているのはメガドライブかもしれない...;;」ということを普通考えなくていいのと同じ、という感じです。

Ohwadaさんは C が読めるので C で例示すると(←型の話になるので分かりやすいと思うので)


namespace XCube
{
  class Controller { .... };
  class Root
  {
  public:
    static Root* getSingletonPtr(void);
    Controller* getController(void) const;
  };
}

namespace Legacy
{
  class Controller : public XCube::Controller
  {
    public:
      /// Legacy 発インターフェイス(仮想関数)
      virtual String getPreferenceUrl(const XoopsModule &module) const;
  };
}



// モジュール側

Root* root = Root::getSingletonPtr();

// 普通にやると XCube::Controller がかえってくるが...

XCube::Controller *controller = root->getController();

// Legacy 用モジュールは当然 Legacy がなくては動かない
// Lgeacy というサブコアに依存したプログラム群。
// だから断定的に Controller を Legacy と判断していい

Legacy::Controller* legacy = static_cast<Legacy::Controller*>(root->getController());

// ↑ Legacy専用モジュールだから断定的にstatic_castしても
//  まぁ...OK。

String url = legacy->getPreferenceUrl(module);



// これは Legacy の派生に意味を持つ

namespace BokutekiLegacy
{
  class Controller : public Legacy::Controller
  {
    public:
      // 仮想関数のオーバーライド
      String getPreferenceUrl(const Legacy::XoopsModule &module) const;
  };
}



// ユーザーは setting_*.ini.php でコンストラクションを
// 変えて、最終実行環境をカスタマイズできる

// Legacy 互換モジュールなので、Legacy用モジュールが動く
Controller=BokutekiLegacy


本来は以下のようになってるのが、キャスト的なことをしなくてよく好ましいですが、 Legacy 用モジュールの場合は XOOPS2 の伝統を引き継いでいるため、これができなかったという感じですね。


namespace Legacy
{
  class Module
  {
    private:
      Controller* m_pController;

    protected:
      Controller* getController(void) const;

    public:
      Module(Controller *controller);
      virtual void execute(void) = 0;
  };
}

void MyModule::execute(void)
{
  String url = getController()->getPreferenceUrl(module);

  // 幸い PHP の場合はそもそもの型に関する仕様が
  // シビアではないので、そこが非常に都合よく働いて
  // くれる。これができなくても、そもそもダイレクト
  // にいけるので...
  //
  // Root::getSingletonPtr()->getController()->getPreferenceURL(...)
  // ↑これで通る!
}


本来の壮大な計画(笑)では、モジュール側の「マニフェスト」に自分が依存しているモジュール "legacy" を書く。ユーザーはこれを legacy ではない legacy に差し替える場合に、 setting_*.ini.php で偽装設定をする。すると、動く、という感じでした。時間と検証不足で、このマニフェストのフォーマット定義は現時点で終わってなくて、テーマで一部導入されるに止まってます。

逐一マニフェストを読んで整合性を確認するわけにはいかないので、基本的には構築補助ツール(←できてないが)などがセッティングの確認で使っていくことになると思います...たぶん。
「Legacy専用モジュール」と「完全別系統新作base」を弾くのはそこで行うことになります(ファミコンソフトをメガドライブに挿せないように...だがパチモンAVファミコンには挿せるように)。

ここでは getPreferenceEditUrl() を使っておけば、
ユーザーレベルでプチカスタマイズされた base や、のちに(それこそ半月後とかに) Legacy 派生 base が出てきたときにも、ユーザーさんに引き続き使ってもらうことが可能なのでみんな幸せ、ということになります。
Re: XC 2.1 と system モジュール 
投稿者: ohwada | 投稿日時: 2007/5/22 21:47
ohwada
力の入った解説 ありがとうございます。

こういうお作法的なことは、どこかに書いてるんでしょうか。

あと1つ。
getPreferenceEditUrl() は legacy が実装しているメソッドですよね。

今後、実装していない ベース・モジュールが出てくると、
Fatal エラーになりませんか。

下記のような形にして、
実装されているときは、しかるべきURLが返ってきて、
実装されていないときは、false を返すとかの方が、
よくないですか。


$root =& XCube_Root::getSingleton();
$url = $root->getUrl('PreferenceEdit');

Re: XC 2.1 と system モジュール 
投稿者: minahito | 投稿日時: 2007/5/22 23:04
minahito
引用:
ohwadaさんは書きました:
こういうお作法的なことは、どこかに書いてるんでしょうか。


xoopscube.org に多少ありますが、まだまだこれからってところです。 Doxygen で多少抜けるようには作ってあります。

引用:
あと1つ。
getPreferenceEditUrl() は legacy が実装しているメソッドですよね。

今後、実装していない ベース・モジュールが出てくると、
Fatal エラーになりませんか。


はい、ただし、先のレスポンスに書いたとおり、
Legacy の API を実装していないベースモジュールというのは Legacy コンパチではないわけですから、 Legacy 専用モジュール自体を動かせませんよね?
(Legacyコンパチと言うことは基本的に Legacy の派生クラスだと思われる)

つまりそのメソッドが動いてフェータルになるという状況...モジュールが起動してその API を呼びだすコードまでプログラムカウンタが到達する、ということ自体、起こりえないと思ってます。

うまいたとえがみつからないのですが、
「女子トイレには小便器がないので、男子が不便。男子が女子トイレに入ったときのことを考えて、小便器をひとつつけておく必要があるか否か」
というような、
「男子が女子トイレに入る」という命題が常に偽かといえば、そうではないから捕まる痴漢がいるんだろうけど、
要/不要に冠しては、これは間違いなく不要だと。そういう感じのことだと思います。


2年ほど前、 Cubeのコンセプトを説明するとき、
Wii のバーチャルコンソール機能(ハードウェアエミュレーション機能)になぞらえたことがありますが...

ここでいう getPreferenceEditUrl() がファミコンの API だとして、
メガドライブの API には getPreferenceEditUrl() がなかったとします。

getPreferenceEditUrl() を使っているファミコンのソフトは、メガドライブの上では getPreferenceEditUrl() にアクセスできず Fatal になるかもしれない。しかし、そもそも、メガドライブエミュレータがファミコンのソフトを起動すること自体、状況的に絶対にあり得ませんから、そのレベルにおける対応は問題ないのです。

つまりモジュールは base の上で動いており、
動作保証のない base の上ではモジュール自体が動かないということです。まったく異なる base の上で XOOPS2 用モジュールを無理矢理動かそうとするときに起こる問題については、考える必要はないと思います。

でも...

引用:
$root =& XCube_Root::getSingleton();
$url = $root->getUrl('PreferenceEdit');


これはいいアイデアですよね。(^^)
文字列の問い合わせは、なにげにプリミティブでいいですよね...最近ちょっとそれが分かってきました。

なにか実害が生じて解決策を Cube レイヤーで持たざるを得なくなったとき、今件に限らず、このアイデア、使わせていただきます。
Re: XC 2.1 と system モジュール 
投稿者: f1rstbear | 投稿日時: 2007/6/19 21:05
f1rstbear
引用:

引用:

minahitoさんは書きました:
引用:
ohwadaさんは書きました:
こういうお作法的なことは、どこかに書いてるんでしょうか。


xoopscube.org に多少ありますが、まだまだこれからってところです。 Doxygen で多少抜けるようには作ってあります。


XC 2.1からのユーザーですが、モジュールを開発しようと既存コードを読んでいます。
手始めに、/modules/lagacy/admin以下がどのようになっているのか見ているのですが、
/html/modules/lagacy/admin/index.php が、

$moduleRunner =& new Legacy_ActionFrame(true);
$moduleRunner->setActionName($actionName);

$root->mController->mExecute->add(array(&$moduleRunner, 'execute'));

$root->mController->execute();

いきなりこれなので、少なくとも
/html/core 以下は全部ソースを読まないと手が出せないの?と思ってしまいました。

実際のところ、coreぐらいは読めよってことなのでしょうか?
Re: XC 2.1 と system モジュール 
投稿者: minahito | 投稿日時: 2007/6/21 13:16
minahito
引用:

f1rstbearさんは書きました:
いきなりこれなので、少なくとも
/html/core 以下は全部ソースを読まないと手が出せないの?と思ってしまいました。

実際のところ、coreぐらいは読めよってことなのでしょうか?


ドキュメントの整備は非常にチマチマですが、進めてますので、まずCVS版を落してDoxygenでドキュメントを抜いてみてください。
(リリースアーカイブはいくつかファイルが抜けているのでダメ)

Doxygenの推奨設定は /extras/Package_Legacy.Doxyfile にあって、ルートディレクトリからの相対で設定してあります。このへんは Doxy を使ったことがある人は好みで...なにしろ埋めきってないので何ですが、生成ドキュメントにある How to R/W Doxygen というページに出力 API の考え方と読み方が書かれています。

現時点では基本的に xoops.org 資料、Doxygen資料をあわせて、不足分をソースで補ってもらうしかないです。

5分〜10分時間が確保できるとまずトラッカーつぶして...という具合にならざるをえないので、どうしても(僕個人が書く)ドキュメント関係は後回しになります。

(海外からのコントリビュートでかなり楽になってきてるんですが、その周辺で作業がいるのでそこで時間とられる...少しずつ片付けていってはいるので、もうちょっとで全面的に楽になってくると思います)

もし「これが足らないから書き足した」というのがあればパッチトラッカーからコントリビュートお願いします。
(xoopscube.org Wiki ないしは sf.net XoopsCube project Wiki に書き足してもらっても構いません。後者ならページルールにしたがって日本語書きもあり)

    投票(0)

    新しいものから | 古いものから | RSS feed
     
    To Top