EC-CUBE 開発コミュニティ

機能要望 > その他 > EC-CUBE2.11.0正式版に向けたソースリファクタリング

その他

投稿者	スレッド
KAJI	投稿日時: 2011/1/28 11:50 対応状況: −−−
一人前登録日: 2008/1/24 居住地: 投稿: 121	EC-CUBE2.11.0正式版に向けたソースリファクタリング株式会社ロックオンの梶原でございます。 2.11.0正式版に向けて、不具合修正を行うことは今まで発表させていただいているのですが、更に、この機にソースのリファクタリング作業を全面的に実施したいと思います！（仕様変更は行いません。あくまでもソースを整理する作業です。）目的はもちろん、カスタマイズ性の向上です。まずは、こちらで、リファクタリングガイドラインのたたきを作成させていただきました。普段、EC-CUBEのカスタマイズ等行っていただいております皆さまに、カスタマイズ性向上という観点で、是非ともレビューいただきたく思います。かなり時間が限られた中ですが、以下の日時までに、色々ご指摘等いただければ幸いです。 ■依頼内容ソースリファクタリングガイドラインへのご指摘、ご意見　⇒ご意見等ございましたら、本スレッドに返信してください。 ■レビュー資料（Tracにまとめました）リファクタリングガイドライン案（EC-CUBE Trac） ■期限 1/31（月）午前中目処追って、皆さまにも（また）リファクタリングご協力のお願いをさせていただければと思っております。 EC-CUBEのカスタマイズ性大幅向上のため、是非ともご協力いただけましたら幸いでございます。（リファクタリング作業自体は2/15まで目処と考えております。）ということで、皆さまお忙しいところ申し訳ございませんが、まずは、たたき台のレビュー、よろしくお願い致します！

AMUAMU	投稿日時: 2011/1/28 13:14 対応状況: −−−
神登録日: 2009/5/2 居住地: 東京都投稿: 2712	Re: EC-CUBE2.11.0正式版に向けたソースリファクタリング _Exクラスの設置についても方針まとめ出来ませんか？ ---------------- EC-CUBE公式エヴァンジェリスト EC-CUBEインテグレートパートナー (株)スピリット・オブ移転・拡張・高速化・問題解決各種カスタマイズ・支援依頼承ります。 [url=h

AMUAMU	投稿日時: 2011/1/28 13:16 対応状況: −−−
神登録日: 2009/5/2 居住地: 東京都投稿: 2712	Re: EC-CUBE2.11.0正式版に向けたソースリファクタリング話題に少し上がっていたSC_Helper系クラスと通常SCクラスとの区分けについても、一応方針が欲しいなと思います。 ---------------- EC-CUBE公式エヴァンジェリスト EC-CUBEインテグレートパートナー (株)スピリット・オブ移転・拡張・高速化・問題解決各種カスタマイズ・支援依頼承ります。 [url=h

red	投稿日時: 2011/1/28 13:40 対応状況: −−−
神登録日: 2010/2/15 居住地: 東京都投稿: 1570	Re: EC-CUBE2.11.0正式版に向けたソースリファクタリング action 関数についてお伺いしたいのですが、その処理だけを行うのであればswitchの部分も内部的に実行してしまえばいいような気がします mode名Actionを動的に呼び、その中で固有の処理を action前に実行したい処理があればpreDispatch action後に共通して呼びたい処理があればpostDispatch といった感じに変更したほうが現代のフレームワークに近い物になると思いますがいかがでしょうか？リファクタリング作業には協力できればと考えております、よろしくお願いいたします

nanasess	投稿日時: 2011/1/28 13:53 対応状況: −−−
神登録日: 2006/9/9 居住地: 投稿: 2314	Re: EC-CUBE2.11.0正式版に向けたソースリファクタリング引用： AMUAMUさんは書きました： _Exクラスの設置についても方針まとめ出来ませんか？現在, data/class 直下の SC_* の多くに _Ex クラスが未設置ですが, この短期間で, 更に修正するとなると, 相当インパクトが大きそうです. いかがでしょうか?

nanasess	投稿日時: 2011/1/28 13:56 対応状況: −−−
神登録日: 2006/9/9 居住地: 投稿: 2314	Re: EC-CUBE2.11.0正式版に向けたソースリファクタリング引用： AMUAMUさんは書きました：話題に少し上がっていたSC_Helper系クラスと通常SCクラスとの区分けについても、一応方針が欲しいなと思います。 SC_Helper 系は, 複数の機能を連携させるビジネスロジック, 通常 SCクラスは, 機能固有のビジネスロジックという棲み分けでいかがでしょう?

nanasess	投稿日時: 2011/1/28 14:07 対応状況: −−−
神登録日: 2006/9/9 居住地: 投稿: 2314	Re: EC-CUBE2.11.0正式版に向けたソースリファクタリング引用： redさんは書きました： action 関数についてお伺いしたいのですが、その処理だけを行うのであればswitchの部分も内部的に実行してしまえばいいような気がします mode名Actionを動的に呼び、その中で固有の処理を action前に実行したい処理があればpreDispatch action後に共通して呼びたい処理があればpostDispatch といった感じに変更したほうが現代のフレームワークに近い物になると思いますがいかがでしょうか？この方法だと, * switch を内部的に実行すると, 全体を見渡しにくくなる * mode名Action() がステートフルになってしまうという懸念があります. ステートフルになること自体は, PHP プログラマの方はあまり気にされないかもしれませんが^^; リファクタリング作業自体は2/15までということで, 変更のインパクトも大きいですし, いかがでしょうか? できましたら, サンプルコードなどご教示ください. 引用：リファクタリング作業には協力できればと考えております、よろしくお願いいたしますありがとうございます.

nanasess	投稿日時: 2011/1/28 14:10 対応状況: −−−
神登録日: 2006/9/9 居住地: 投稿: 2314	Re: EC-CUBE2.11.0正式版に向けたソースリファクタリング本件とは少々外れてしまうかもしれませんが, 下記のようなご提案もいただいています. #909 モデルクラス (ghana様) http://svn.ec-cube.net/open_trac/ticket/909

ECCUORE	投稿日時: 2011/1/28 14:40 対応状況: −−−
長老登録日: 2009/10/22 居住地: 東京投稿: 248	Re: EC-CUBE2.11.0正式版に向けたソースリファクタリング期間的は難しいと思いますが、その思想は好きです。ステートフルの件にしても、アクションヘルパー的な物を使えばクリアになるでしょうし、プラグインも高機能化しそうですしね。「ソースリファクタリングガイドライン案」で一旦、MVCっぽくしておけば、red様提案の思想に再度リファクタリングするのに手間が掛らないのでは無いかと思いますので、次バージョン以降、是非また提案してください。その時を楽しみにしています。この思想だと、プラグインでmodeActionを上書きしたり、追加したりと色々出来そうですね。 ---------------- EC CUORE 株式会社クオーレカスタマイズ御相談下さい。

red	投稿日時: 2011/1/28 14:54 対応状況: −−−
神登録日: 2010/2/15 居住地: 東京都投稿: 1570	Re: EC-CUBE2.11.0正式版に向けたソースリファクタリング 2.4.4で作ったものですが LC_Pageと各ページクラスの間に独自クラスを作りましてそのなかで `public function process() { parent::process(); $this->preDispatch(); if (!isset($_POST['mode'])) $_POST['mode'] = "index"; call_user_func_array(array($this, $_POST['mode'] . "Action"), array()); $this->postDispatch(); self::display($this); }` そしてページクラスでは `public function confirmAction() { $this->arrErr = self::lfCheckError($this->arrData); // 入力エラーなし if(count($this->arrErr) == 0) { // DBへのデータ登録 self::lfRegistData(); parent::redirectNextPage(); } } // post payment ** 空だけどjs動かす為に必要 public function paymentAction() { }` こんな感じでmodeでActionを動かしています。根っからのPHPerでちゃんと勉強したことがないので好きなように書いてしまっていますが･･･利点としてはこの基底クラスで必ず `$this->objFormParam = new SC_FormParam(); $this->lfInitParam(); $this->objFormParam->setParam($_POST);` こういった処理を呼ぶようにしていますのでPageクラスではスーパーグローバルが出てくることが絶対にないということでしょうか確かに時間も厳しいですがなにかの参考になれば幸いです

(1) 2 3 4 »