シーソフト様

> 判定が必要・不要というのは、どのような基準でしょうか?
LC_Page(LC_Page_Admin)のpreProcess,processでは事前にプラグイン管理画面であるかを判定し
その結果を$this->plugin_activate_flgに代入し下記の様にインスタンスを取得しています。
> SC_Helper_Plugin_Ex::getSingletonInstance($this->plugin_activate_flg);
そうする事でプラグイン管理画面ではプラグインが呼ばれなくなります。

背景としては、プラグインのアップデート処理の仕様です。
プラグインのアップデートは新規プラグインクラスをリクワイヤして、そのupdate関数を実行する仕様となっています。
この際にLC_Page_AdminのpreProcessで有効なプラグインが全てリクワイヤされているので
新規プラグインのクラス名が衝突し、リクワイヤできないという問題が発生しました。
その対応としてプラグイン管理ではプラグインを実行(リクワイヤ)しないという仕様にしています。

ですが、混乱を招く実装になっている様ですので、全体的にリファクタリングした方がよさそうですね。

> フックポイント名の中のクラス名って、クラス名のまま(大文字小文字混在)にはできないものでしょうか?
こちらご提案頂いた内容の方が、可読性も良さそうですので対応させて頂きます。

雑文で申し訳ありませんがよろしくお願いいたします。


ECCUORE様

>「プラグインによる追加テンプレートファイル」命名規約も必要かと思います。
ありがとうございます。
命名規約に関してはしっかり決めていく必要がありそうです。
DBへのテーブル・カラム追加やファイルの追加など、様々なケースで想定されますので
こちらで一度規約を作らせて頂きます！

便乗要望になりますが、フックポイント名と同じように、「プラグインによる追加テンプレートファイル」命名規約も必要かと思います。

----------------
EC CUORE 株式会社クオーレ
カスタマイズ御相談下さい。

内部を理解していないので、的外れなことを言っているかもしれませんが・・・


フックポイント名の中のクラス名って、クラス名のまま(大文字小文字混在)にはできないものでしょうか?

今後の本体開発で typo の温床になりそうな気がして。

現状のクラス配置でも、キャメルケースとスネークケースの使い分けで苦労するシーンがあるのですが、更にどちらでも無い新たな記述方法が追加されるのは本体の開発負荷となりそうな気がしております。


また、読みやすさの観点でも、
「lc_page_frontparts_bloc_searchproducts_action_start」よりも
「LC_Page_FrontParts_Bloc_SearchProducts.action_start」などの方が、優れているような気がしております。

(「.」の部分は、テキトーですが、「_」ではない区切り文字が入ると読みやすいかもと。)

----------------
Seasoft
こちらでの投稿は、アイディア程度に留めさせていただいております。
個別案件の作業は有償で承っております。お気軽にご相談ください。

yoshimoto 様

判定が必要・不要というのは、どのような基準でしょうか?

同一クラス内でもバラツキがあるようで、混乱を招きそうな印象を受けております。

----------------
Seasoft
こちらでの投稿は、アイディア程度に留めさせていただいております。
個別案件の作業は有償で承っております。お気軽にご相談ください。

お世話になっております。
株式会社ロックオン吉本です。

nanasess様

> * regist という英単語はありませんので, register に修正した方が良いと思います.
> http://labs.cybozu.co.jp/blog/akky/archives/2005/07/regist.html
ご指摘ありがとうございます。
こちら対応させて頂きます。


seasoft様

> 下記2通りの呼び出しが混在しているようですが、どういった違いでしょうか?
> SC_Helper_Plugin_Ex::getSingletonInstance($this->plugin_activate_flg);
> SC_Helper_Plugin_Ex::getSingletonInstance();
$this->plugin_activate_flgはプラグイン有効なプラグインを呼び出すかの判定フラグとなっています。
判定が必要な箇所には引数で渡す様にしています。
（例えばプラグイン管理ではプラグインが動作しない仕様になっています。）

判定が不要なクラスに関しては省略しています。
（デフォルト値がtrueなので）

下記2通りの呼び出しが混在しているようですが、どういった違いでしょうか?

SC_Helper_Plugin_Ex::getSingletonInstance($this->plugin_activate_flg);
SC_Helper_Plugin_Ex::getSingletonInstance();

----------------
Seasoft
こちらでの投稿は、アイディア程度に留めさせていただいております。
個別案件の作業は有償で承っております。お気軽にご相談ください。

細かいところですが...

* regist という英単語はありませんので, register に修正した方が良いと思います.
http://labs.cybozu.co.jp/blog/akky/archives/2005/07/regist.html

* プラグインのライセンスはどうなるのでしょうか? GPL or LGPL でしょうか? Apache ライセンスなど, GPL に矛盾しないOSSライセンスでしたら頒布可能でしょうか?

はい!
そちらの認識で問題ありません。

α版をリリースさせて頂きましたのでご確認よろしくお願いいたします！
http://xoops.ec-cube.net/modules/newbb/viewtopic.php?topic_id=10155&forum=14&post_id=48550#forumpost48550

改めて仕様とサンプルを載せておりますので、また不明点など御座いましたらご連絡頂ければと思います。
よろしくお願いいたします。

2パターン（「1項目追加する」、「1画面追加する」）での処理の流れは概ね理解いたしました。

＜私の理解した処理イメージ＞
_smarty register_prefilter　に　Smartyフックポイントprefilter_transformを登録
↓
view prefilter_transform　で　フックポイントprefilter_transformの関数を実行（objPageインスタンスの）

SC_Helper_Transformについては、もう少し詳細を追ってみます。

「1項目追加する」プラグインと、「1画面追加する」プラグインの動作確認用に2つほど作成しようかと思ってます。
完成まで御付き合い頂けると幸いです。

----------------
EC CUORE 株式会社クオーレ
カスタマイズ御相談下さい。

お世話になっております。株式会社ロックオン吉本です。
お答えさせて頂きます。

> ■「管理画面の商品情報に1項目を追加するプラグイン」ケースについて
こちらはテンプレートへのトランスフォームとフックポイントの2機能を使う事になります。
項目の追加はテンプレートのトランスフォームを使います。

下記の流れでSmartyは処理しますが、そのコンパイルファイル作成前にテンプレートのソースに干渉出来る様になっています。
テンプレート→コンパイル→変数に値の割り当て→出力

他のフックポイントと同様にコンパイル前に処理を追加できるフックポイントをaddActionをします。
この場合、prefilterTransformというフックポイントになります。
$objHelperPlugin->addAction('prefilterTransform', array(&$this, 'prefilterTransform'), 1);

こうしておくとSmartyのコンパイル時にセットしたコールバック関数prefilterTransformが実行されます。
prefilterTransformにはテンプレートのソースが渡るので
SC_Helper_Transformというインターフェイスを使ってソースを好きに整形→コンパイルファイル作成
（SC_Helper_Transformの使い方は仕様書を作成しますのでもうしばらくお待ちください）

という流れになります。

追加した項目への処理はPageクラスのフックポイントで行います。
（メンバ変数にセットして出力など…）

> ■「御届け先の指定画面→（プラグインで追加される画面）→お支払方法画面」のように1画面丸ごと追加するプラグインのケースについて
やり方いくつかあるかと思いますが、お支払方法画面のフックポイントで追加画面に飛ばす事になるのかと思います。


まだまだ見えてない点が多くありますので、実際に実現出来ない・問題があればα版で修正していきたいと思います。
よろしくお願いいたします。