autoloaderの実装 about ec-cube HOT 17 CLOSED

autoloader に関係して、PSR-0 や PSR-1 への準拠は想定されていますでしょうか。

from ec-cube.

ディレクトリ構造の変化を伴うPSR-0への準拠は予定しておりません。
コーディング規約の面では、PSR-2へ準拠したいと考えています。

from ec-cube.

承知しました。ありがとうございます。

from ec-cube.

EC-CUBE のディレクトリ構造は対応していなくても、 autoloader は名前空間を基にしたオートロードに対応してほしいですね。
そうでないと、現在でも利用できるライブラリが限られてきているのに、今後ますます選択肢がなくなって、もう何年も更新されていないようなツールしか使えなくなりそうです。

from ec-cube.

ぜひ、data/module 以下だけでも composerに移行して、vendor/autoload.php へ移行していただきたいです。

from ec-cube.

@pineray

EC-CUBE のディレクトリ構造は対応していなくても、 autoloader は名前空間を基にしたオートロードに対応してほしいですね。

そうですね。開発方針にもnamespace対応をしめしているので、それに沿った形で実装しましょう。

from ec-cube.

@ttsuru
PEAR使うのか、というのも含めて議論したいですね。
composer対応は、autoloaderと切り離して、別でissueたてて話した方がよさそうでしょうか？

また、issue運用に関してなのですが、issueはミニマムな構成にしていきたいと考えているので、話が別の領域までいく際は、関連付け（コメントに#Xをつける、でOK）をしたうえで別にissueを立てる方向でお願いします。
（もし、一般的でなければご指摘ください）

from ec-cube.

@shinichi-takahashi
issueについては小さい単位というのはいいと思います。
Labels で enhancement や bug などついてると追いやすいと思います。

PEARを使うのか自体ということですが、品質を担保し同じ内容を実装するのも大変なのではと思ってしまいます。
ComposerについてはComposerで定義をすれば、autoloaderのファイルまで生成されるため、同時の議論の方がよいかと思いますがいかがでしょうか。

以下、参考ソースになります。
https://www.softel.co.jp/blogs/tech/archives/4057

from ec-cube.

@ttsuru
なるほど、であれば本issueにてやり取りしていきましょう。

ComposerについてはComposerで定義をすれば、autoloaderのファイルまで生成される

こちら、確かにそうですね。
一旦、現状のEC-CUBEの依存パッケージorこれからのEC-CUBEの標準としたいパッケージを
composer.jsonに書き出すべきでしょうか。

from ec-cube.

こちら、とりあえず実装したものをPull Requestを投げさせていただきました。

autoloadについて

PSR-0への対応は行わないとのことですが、PSR-4であれば今後のNamespaceにも対応できるのではないでしょうか。
ComposerはPSR-4のautolodに対応しました。

プラグインのフック方法について

現在のSC_*のフック方法ですが、何か他のいい実装方法はないのでしょうか。
同じメソッドをchainしたりできないのは不便ではないでしょうか。

プラグインのインストールについて

例えば、今後はcomposerと同様の形式にしてしまえば依存関係も一気に解決するような気がします。

ロジックは以下のイメージです。
dtb_pluginへ書き込み->composer.json(もしくは外部ファイルに書き込み)->composer install

composer ではpre-install-cmd post-install-cmd pre-update-cmd post-update-cmd などがあり、現在のプラグインインストールに該当する内容も実装可能です。
また、Pluginのautoload対応や、updateもよりやりやすくなると思います。

最近Wordpress界隈で話題の ``wp-cli` っぽいような感じにもできそうな気がします。

from ec-cube.

@ttsuru
pull requestいただきありがとうございます！
ベースとなる部分なので、早いうちにmergeできるよう確認進めたいと思います。

from ec-cube.

プルリク確認しました。
data/module/以下にfpdfとgdthumbが残ってしまいますが、こちらはどうしようもないですかね・・・？
本プルリクの採用についてはもう少しだけissueで継続して相談させてください。

from ec-cube.

@shinichi-takahashi
gdthumb については古くカスタマイズなどもしにくく感じますので、他のライブラリへの移行が良いと思います。
fpdfについては特に日本語対応のJapanese部分があるため、autoload.phpの対応だけであれば可能だと思いますが、とりあえずは残しておきました。
コミットについてはまずはPEAR部分のComposer化とさせていただき、残り部分は後日検討でいかがでしょうか。

from ec-cube.

@shinichi-takahashi
@ttsuru
リリース用のパッケージ(*.tar.gz, *.zip) には、 PEAR のパッケージも同梱する認識で合っていますか？
Composer の使えない環境も多々あると思いますので。。

from ec-cube.

@nanasess
その認識であってます。
Composer対応はあくまで開発用で、パッケージでは一般的なレンタルサーバ（SSH接続なし）でインストールできることを想定しています。

from ec-cube.

リリース用のスクリプトも修正が必要ですね。

from ec-cube.

Composer導入と@ttsuruさんのPRをマージしたため、本件クローズいたします。
ご対応いただいたみなさま、ありがとうございます。

from ec-cube.