-
主に、ユーザーがカスタマイズするコードは
app/Eccube
以下に置きたい -
src/Eccube
以下のコードは、極力触らないようにしたい- 修正したい場合は
app/Eccube
以下でオーバーライド - 必要なコントローラのみオーバーライドすれば良いので、2系の extends よりわかりやすいはず
- プラグインがコントローラを継承しないように、構造で何とかしたい
- 修正したい場合は
-
SubRequest(forward) を有効活用して、コントローラをチェーンにしたら便利かも
-
Doctrine の Embeded アノテーションを使う
-
Sylius は参考になる
-
こんな感じにインストールできる
-
composer create-project -s beta sylius/sylius-standard acme cd acme php bin/console sylius:install npm install npm run gulp php bin/console server:start open http://127.0.0.1:8000 ``` - インストーラの途中でサンプルデータのインストール可否を聞かれる。インストールすれば、デモサイトができあがる
-
もっと、とっつきやすい感じにしたい
- WordPress の子テーマのようなイメージ
- app/template の下に子テーマを作るようにしたらわかりやすいかも
- Bundle ベースだと、 Symfony Bundle の仕組みを理解していないと難しい
- 仕組みを理解していなくても、とりあえずカスタマイズして、何とかなるようにしたい
- Controller の dispatcher をつくればいいかも
- WordPress の子テーマのようなイメージ
-
Controller のプロパティをテンプレートに渡したい
-
メソッドの返り値をテンプレートファイル名にしたい
-
@Response アノテーションとかで生のレスポンスを返したり, Response オブジェクトを返したりしたい
-
Silex\Controller を継承すれば, 今まで通り
-
フォーム等の前処理を before middleware にもっていきたい
-
コントローラメソッド同士を SubRequest でつなげられれば, 継承ではなく移譲できる
-
メインの処理は, SubRequest を返すコントローラメソッドをつなげるだけ ← Reactive programing に近い
-
できるだけ小さな処理をするメソッドに分割しておく ← 2.0の頃から目指していた実装
-
カスタマイズする場合は, 小さなメソッドをオーバーライドする ← 移譲であれば複数のプラグインからカスタマイズ可能
-
コントローラの処理の流れを変えたければ, メインコントローラをオーバーライドする ← ここにビジネスロジックは含まれないはずなのでフックポイントの影響を受けにくい
-
プラグインでは trait & 継承
-
trait を使えば独自拡張も楽にできる
- Proxy クラスを使えば, もうちょっと柔軟にできるけど, わかりづらくなる
-
もうちょっと変えたい場合や, 独自カスタマイズの場合は app/Eccube/Entity 以下のクラスを使う
- Inheritance Mapping
- Association Override などを使用する
http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/inheritance-mapping.html http://tech.quartetcom.co.jp/2015/08/24/doctorine2-inheritance-mapping/
SensioFrameworkExtraBundle が使える https://github.com/sergiors/sensio-framework-extra-service-provider
一番イメージに近い. Yaml ではなくてアノテーションにしたい https://github.com/lastzero/symlex
Reactive Programing が主流になりそうな感じ. 関数型 https://spring.io/blog/2016/07/28/spring-framework-5-0-m1-released
Linq さいこうらしい https://www.microsoft.com/net/core/platform
- 無駄にコントローラの実装がでかい
- カテゴリツリーの構造変更(EC-CUBE/ec-cube#1854)
- 規格と別に、商品オプションがほしい
- フロント、管理画面と実装が分離している
- できるだけ共通化する
-
決済情報入力完了後、EC-CUBE へ戻ってこれずにブラウザを閉じてしまった場合の問題
- 購入完了メールが送信できない
- 在庫が減ったままになる
- 受注ステータスが「決済処理中」「購入処理中」のままとなってしまう
- 店舗側が購入に気づかない
- 決済システム上は支払い済みとなってしまう
- 決済情報通知などを利用することで軽減可能
-
shopping/confirm のフックポイントが呼ばれない問題(FRONT_SHOPPING_CONFIRM_INITIALIZE で別画面に遷移してしまう)
- FRONT_SHOPPING_CONFIRM_PROCESSING
- FRONT_SHOPPING_CONFIRM_COMPLETE
- 上記フックポイントを使用しているプラグインとは共存できない
-
戻り・キャンセル処理が統一されていないため、独自に実装しなければならない
-
ShoppingService::notifyComplete() では、状態遷移がわからない懸念
- 更新前受注ステータス、 更新後受注ステータスがとれるようになってないと困るのではないか
-
決済入力中に在庫がなくなった場合は、在庫数が -1 になってしまう
-
コンビニ決済などで、期限切れになった場合の在庫処理
-
リンク式以外でも、決済サーバーと通信中に在庫切れになった場合はロールバックできずに、在庫数が -1 になってしまう問題がある
- ポイントプラグインでは、利便性の問題から警告を出すのみに留めているが、在庫数の問題はより深刻である
- 2系と同様に、決済処理中となった段階で在庫を確保しておく必要があるのではないか(→方針を決めてください)
- 本体側に、注文の途中キャンセルや「戻る」際の共通処理を実装しておく
- 本体側に、購入完了処理(DBに受注データ一式生成して、カートをクリアして、メール送信)をコントローラではなくサービスとして実装する
- 受注データの構成変更にも関連すると思われる
-
PHP5.5以上でないと動作不可
FatalErrorException in GmoEpsilon_Base.php line 84: Compile Error: Can't use method return value in write context
-
購入完了処理を独自に実装している
-
以下のフックポイントは呼ばれない
- FRONT_SHOPPING_CONFIRM_PROCESSING
- FRONT_SHOPPING_CONFIRM_COMPLETE
-
決済完了通知(epsilon_pay_complete.php)でステータスを更新している
-
決済完了後、EC-CUBE に戻ってこれなかった場合は決済完了通知でステータスは更新される。
-
ShoppingService::notifyComplete() はコールされないため、ポイントプラグインとの連携ができない(何回でもポイントが利用可能)
-
改行コードが CR になっているプログラムが存在する
- GmoEpsilon/Service/Client/GmoEpsilon_Regular
- epsilon_pay_complete.php
-
決済入力中に在庫がなくなった場合の対応
-
正常購入完了後、在庫が減らない不具合あり(http://xoops.ec-cube.net/modules/newbb/viewtopic.php?topic_id=17457&forum=12&post_id=76056)
- 購入完了処理を独自に実装している
- 以下のフックポイントは呼ばれない
- FRONT_SHOPPING_CONFIRM_PROCESSING
- FRONT_SHOPPING_CONFIRM_COMPLETE
- ShoppingService::notifyComplete() はコールしている
収納通知通知(/shopping/remise_acpt)でステータスを更新している- 決済は確定していて、EC-CUBEに戻れなかった場合、
- カード決済の場合は、決済は完了し、受注未確定というステータスになる。在庫は減らない。
- マルチ決済の場合は、決済情報は送信され、決済処理中となる。在庫は減らない。
- ShoppingService::notifyComplete() はコールされないため、ポイントプラグインとの連携ができない(何回でもポイントが利用可能)
- 決済入力中に在庫がなくなった場合は、在庫数が -1 になってしまう
- なぜかクレジットカード決済の名称変更ができない
原因不明のシステムエラーで、テスト環境へ接続できず
- Symfony のサポート期間が約4年と長くはない
- 現行の2.7は2019年5月まで、2.8は2019年11月まで。
- 2.8 に上げた場合、もちろんプラグインも影響を受ける
- まじめに追従しようとすると、約4年ごとにメジャーバージョンアップの必要がある。
- 実際には、1年程度経過してから採用→案件に採用されてリリースされたらあと2年しか保守されないってことになりかねない
- ECサイトは最低7〜8年は保守できないと、回収もままならない ため、ミスマッチである
- Silex は、どこまで保守されるか不明瞭
- 一応、 Symfony3.1 でも動作するっぽい
- Symfony3.2 の issues がでてる
- Silex2系に対応してみたブランチ(動かない) https://github.com/nanasess/ec-cube/tree/improve/silex2
Silex 1.x の SecurityServiceProvider が Symfony3.x で削除されたクラスに依存しているため、 Silex 1.x は Symfony2.8 までしか利用できない模様。
これから次期メジャーバージョンを開発するのなら Symfony 3.4 のリリース(2017年11月)を目標にするのが良いのではないか。 ただし, PHP5.5.9 以降のサポートとなってしまう. RHEL/CentOS7 の PHP5.4 よりもサポート期間が短いのに注意。
https://github.com/symfony/symfony/blob/master/UPGRADE-3.0.md