134 様

標準プラグインの実装は, 「LC_Page::process() 関数を乗っ取る」といった強引な実装なので, それよりもスマートな印象ですね!

現在の EC-CUBE は, どうしても PHP4 が離せないので, PHP5 限定なのが気になっています.

また, プラグイン間の排他制御や依存関係の制御を実装する予定はありますでしょうか?

せっかく PHP5 を使うのであれば, Dependency Injection や AOP などのデザインパターンで, もっと柔軟かつ, 開発効率の良いプラグインフレームワークができるのでは... と思っている今日この頃です.

「学習コストが低く, 開発効率の良いプラグイン」というのも, なかなか難しい課題ですが^^;

個人的には現段階のEC-CUBEではプラグイン機能の実装は難しいと思っています。

過去に似た様な事をやった際はhtmlエリアのphpファイルを置き換えて、呼び出すページクラスを置き換えてコアのコードを変えない様にしていました。

プラグイン同士の衝突に関しては諦めるしか無いと思います。
（これはどのCMSでも同じだと思います）
次期バージョンあたりで、プラグイン用のフックをいくつかコアのコードに入れられたら融通が効く様になると思いますが、コア自体をプラグインありきと言うか、プラグインの固まりの様な物にしないと、なかなか難しいと思います。

concrete5というCMSにも関わっていますが、こちらはプラグイン（アドオン）ありきの設計になっているのでその辺は非常に勉強になります。

----------------
EC-CUBEカスタマイズ相談してください。
緊急のEC-CUBEの障害対応
EC-CUBEカスタマイズブログ

nanasess様

> 現在の EC-CUBE は, どうしても PHP4 が離せないので, PHP5 限定なのが気になっています.

新機能ですので、PHP5 のみ対応として、
PHP5 への移行を促したいと意思もあります。

> プラグイン間の排他制御や依存関係の制御

現在はヘッダコメント内で簡単な依存関係の設定を持つようにしていますが
Interface での依存関係の制御ができれば良いかとは考えています。
排他制御は、インストールのブロック程度は可能でも、
動作レベルでの排他は現実的には難しいかと考えています。


tao_s様

> 過去に似た様な事をやった際はhtmlエリアのphpファイルを置き換えて、呼び出すページクラスを置き換えてコアのコードを変えない様にしていました。

「htmlエリアのphpファイル」とは、HTMLテンプレート内に PHPファイルを include するようなことでしょうか。
なるべく既存のテンプレートにでも適用できるように、という考えで、今回の実装にしてみました。

> 次期バージョンあたりで、プラグイン用のフックをいくつかコアのコードに入れられたら融通が効く様になると思いますが、コ> ア自体をプラグインありきと言うか、プラグインの固まりの様な物にしないと、なかなか難しいと思います。

そうですね…ここがハードルだとは思っています。

> concrete5というCMSにも関わっていますが、こちらはプラグイン（アドオン）ありきの設計になっているのでその辺は非常に勉強になります。

concrete5 に関わってられるのですね。
これまで MODX で構築していたようなサイトは、concrete5 のほうがよさそうだな、
と思っていたところでした。また勉強させて頂きます。

最近忙しくて１ヶ月ほどコミュニティに顔を出していませんでしたが、プラグインと聞いて早速拝見させて頂きました。

かなり良い実装で大変参考になります。
自分の方でもいくつかEC-CUBEプラグインの実装検討等をしていたので尚更参考になるところです。

PHP4系との互換性を考えると、eval使うような、かなり泥臭い実装も方法論としてはありますが、PHP5専用となれば実装方法の幅も広がるでPHP5専用化は致し方ない所かなと思います。

個人的に思うところはPHP5専用にするのであれば、リフレクションを用いて、よりスマートにかつ高速な実装を検討したいところです。
（PHP5のリフレクションはパフォーマンスが高いです。フレームワークのsymfony2等でも実績があり、参考にもなります。）

個別で見ると、フック部分は設定情報化＆キャッシュ化することにより、コールバック関数単位でのpriorityの半固定化をするとともに、それらを管理・再生成をする管理画面を用意すると良いのかもしれません。
競合制御を使う側に委ねられる、速度面での有利化、軽量化、環境差異による動作問題を手動設定させる余地などが生まれるのではないかと思います。

移行としては最終形はプラグインの塊にする事を念頭に、どう置き換えて行く事が可能かを考える方が良いかもしれません(パフォーマンス面、環境依存性の排除、既存ノウハウの移行なども考慮点てに入れたいのですが・・・）。

プラグインの導入・更新などはWordPressのような、かつ今のオーナーズストアに変わるような物と連結することを考えると良いとは思っています(プラグインストア？）。

また一方で、自分は既存の2.11系プラグイン機能を用いたモジュールをいくつか作っている為、今後の中でプラグイン・モジュールなど後から足す機能の混在などに懸念を抱いています。

プラグイン周りの検討は株式会社ロックオン社の方でも検討課題にあがっているらしいので、音頭を取って頂けると嬉しいのですが・・・

----------------
EC-CUBE公式エヴァンジェリスト
EC-CUBEインテグレートパートナー (株)スピリット・オブ
移転・拡張・高速化・問題解決
各種カスタマイズ・支援依頼承ります。
[url=h

＞標準プラグインの実装は, 「LC_Page::process() 関数を乗っ取る」といった強引な実装なので, それよりもスマートな印象ですね!


個人的には強引さや、使い込めば結構融通が利くところがEC-CUBEっぽくて、今のプラグインの実装手法は結構好みです(笑

----------------
EC-CUBE公式エヴァンジェリスト
EC-CUBEインテグレートパートナー (株)スピリット・オブ
移転・拡張・高速化・問題解決
各種カスタマイズ・支援依頼承ります。
[url=h

引用：
そう言えば以前株式会社ロックオンの方にEC-CUBE用のプラグインのマーケットプレイスが欲しいみたいな話しました。

個人的にはEC-CUBEにはHTMLエリアの各pageクラスを呼び出すphpファイルを止めてdispacherとかでルーティングして欲しいです。
その方がプラグインも色々作りやすいと思うんですよね。

----------------
EC-CUBEカスタマイズ相談してください。
緊急のEC-CUBEの障害対応
EC-CUBEカスタマイズブログ

引用：

下記２つの側面で現状のような形になったような話を随分昔に聞いたことがあったようなないような・・・

1.レンタルサーバーでの動作問題（実質的にrewriteモジュール必須という意味で？ 現状がFilesだけでも諸処の制御可能なのは確かに環境対応としてはメリット？）

2.古い携帯向け対応を考えたときに長いURLになるとブックマークが切れたり、セッションが切れる恐れがある

個人的にはdispacher歓迎です

----------------
EC-CUBE公式エヴァンジェリスト
EC-CUBEインテグレートパートナー (株)スピリット・オブ
移転・拡張・高速化・問題解決
各種カスタマイズ・支援依頼承ります。
[url=h

ソースを良く見ていないですが、皆さんのソースレビューを呼んでる限りでは標準のプラグインよりも高機能かなと思いますし、WPライクなプラグインは好きです。

134さんは、プラグインの干渉を気にしてらっしゃいますが
フックポイントを利用したプラグインの場合はどうしても干渉が起こると思いますし、そこは気にしてもしょうがないかなと。
実際に、WPでは干渉で動かなくなったりするプラグインもありますからね。

ただ、WPの場合は動かなくても用途がブログ利用であれば、多少ストップしても問題無いですが
ECサイトはストップするのはマズイ気がするので、EC-CUBE利用者の立場から考えると
「管理者、店長」が気軽にプラグインを入れる事が出来るってのが運用上怖い気がします。（標準のプラグイン機能にも言える事なのですが）

しかし、開発者の立場としてはハイレベルなプラグイン機能が標準に適用されるのであれば、是非とも利用したいですし、プラグインの開発もしてみたいなと思います。

なんか一見否定的な発言で申し訳ないです。
本当はプラグイン好きです・・・

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

AMUAMU様

ご意見ありがとうございます。

> 個別で見ると、フック部分は設定情報化＆キャッシュ化することにより、コールバック関数単位でのpriorityの半固定化をするとともに、それらを管理・再生成をする管理画面を用意すると良いのかもしれません。
> 競合制御を使う側に委ねられる、速度面での有利化、軽量化、環境差異による動作問題を手動設定させる余地などが生まれるのではないかと思います。

このあたりの具体的なイメージが沸かないのですが、もう少し具体的にお聞かせ願えませんか？

tao_s様

すみません、話の流れで「htmlエリアのphpファイル」の意味が分かりました。
今回はプラグイン用の新規ページのみ、なんちゃて dispatcher を挟んでいますが、
標準機能としてプラグイン機構を考えた場合には、コアの制御も検討が必要ですね。
混じっているのは気持ち悪いです（笑）

＞このあたりの具体的なイメージが沸かないのですが、もう少し具体的にお聞かせ願えませんか？

ちょっと後日となりますが少しコーディングしてみたいと思います

----------------
EC-CUBE公式エヴァンジェリスト
EC-CUBEインテグレートパートナー (株)スピリット・オブ
移転・拡張・高速化・問題解決
各種カスタマイズ・支援依頼承ります。
[url=h