ec-cube / ec-cube Goto Github PK

Vagrant を利用して、簡単に開発環境を構築できるようにする

See Also.

https://github.com/nanasess/vagrant-lamp

以下の議論でも挙がっていますが、
#7 (comment)
#7 (comment)

DIコンテナを使えば、依存関係も上手く制御できると思います。（テストも書きやすくなります。インターフェースを考えなおす良い機会にもなるでしょう。）是非、検討して頂ければ幸いです。

app/cache/ 以下はそれぞれのロジックで自動的にディレクトリが作られるので、トラブルやインストールの簡素化のためにも、cache のみをパーミッション777で置いておくようにしてはどうでしょうか。

私が、2/13(金)目途で、以下の構成の注文ロジックのモックを作成します。
その後、WIPとしてPR投げますので、皆様にモックをレビューしていただきたいと思います。

レビューを重ね、PRが問題ないと判断でき次第、そのPRを本リポジトリにマージします。
その後、マージしたPRをサンプルコードとして提示したいと思います。
Sessino, DataBaseについては、どの機能を開発するにあたっても、必要になってくると思いますので、
随時見直しをしていきます。
疑問に思ったり、変えたいときは、別途Issueをたててください。

• ディレクトリ(レイヤー)構成
  • Repository - DB操作
  • Service - ビジネスロジック
  • Controller - ViewとServiceつなぐ
  • View
  • Plugin - 上記を包含するものか、別構成にするか検討
• クラス構成
  • Repository
    • CustomerRepository
    • ProductRepository
    • etc
  • Service
  • Controller
    • 機能単位
  • View
    • 画面単位
• Event
  • どこでどういう形で利用するか要検討

• Session
  • cart
  • auth
• DataBase
  • テーブル設計

テーブルについているprefix「dtb_」「 mtb_」をはずす

必須条件

• 日本語対応している
• カスタマイズが容易

理想

• ミリ単位での指定ができる
• Packagistに登録されている

候補

• fpdf
• mPDF
• ThinReports
  などを検討していますが、長い目で見てどれがいいか議論の上で決定したいと思います。

直接実行を考慮

DoctrineORM DoctrineDBALなどのORMの利用を積極的に検討

懸念点・判断基準は以下。

• 性能面：著しく実行速度が遅くならないか
• MySQL/PostgreSQLのauto incrementの違いを吸収するか
• 生のSQLを投げて実行させることができるか

候補は以下？他に候補があれば、コメントください。

• Doctrine ORM
• Doctrine DBAL

しばらくインストーラーも動作しない感じで、実際の動作を試せていないのですが、どんな感じで環境構築するのでしょうか?

• 構造の違うmtb_系テーブルを除き、ひとつのテーブルとする。
• 既存の各テーブルを分けるために、「type」カラムを用意する。

ただし、id, name, rank以外の構造のmtb_（mtb_constants / mtb_zipなど）は別table（constants / zip）とする

Silexベースのコードへのリファクタリングの進捗とその疑問点などをまとめるIssue

リファクタリングへの参加方法

1. 下のリファクタリング対象一覧の確認
2. 自分が対応したい画面のAssigneeにGitHub IDを記載
3. リポジトリをフォークし、フォークした自分のリポジトリでブランチを切って開発
4. 開発完了後、PullRequestを送信する（Pull Request前にテストコードを作成することを推奨）

• リファクタリング対象一覧
  https://docs.google.com/spreadsheets/d/1df5Sc4eoEQv4ZVm6_q8-QE0-PduS2gnAtNXVQco0x-8/edit?usp=sharing

リファクタリングのルール

• リファクタリングガイドラインを参照
• 不明点はIssueのコメントやSlackを活用

Wikiに、[EC-CUBE3　機能要件]と[開発要件]の２つのページを作成いたしました。
[EC-CUBE3 機能要件]は変更が入ることはほとんどありません。

[開発要件]について、意見をいただきたく本Issueを作成いたしました。
[開発要件]は本リリースまで適宜ブラッシュアップをしていきたく、皆様のご意見をこちらで集約させていただきたいと思います。

2.13系にデフォルトで含まれている機能だが、

• ECとしての役割がうすいもの
• フラグでON/OFF切り替えているもの

を、デフォルトでインストールされているプラグインとして扱う

• 商品レビュー投稿機能
• ポイント機能

data/ClassLoader.phpを作成し、全classをautoloadできるようにする

Travis CI
https://travis-ci.org/EC-CUBE/ec-cube

Coveralls
https://coveralls.io/r/EC-CUBE/ec-cube

Coveralls については連携がなかったようです。
また、バッジも貼り付けてはどうでしょうか。

[![Build Status](https://travis-ci.org/EC-CUBE/ec-cube.svg)](https://travis-ci.org/EC-CUBE/ec-cube)
[![Coverage Status](https://img.shields.io/coveralls/EC-CUBE/ec-cube.svg)](https://coveralls.io/r/EC-CUBE/ec-cube)

そもそも設置する/しないの話から皆様のご意見を頂戴できればと思います。

通常利用しているデザインテンプレートが存在しない場合に、他のデザインテンプレートを探す仕組みを検討中

背景

３系では、アップデートに対応したいので、以下の事が考えられる

• デフォルトで持っているデザインテンプレートのファイルを直接編集することはNG
• アップデート後に新たに追加されたページが表示されるように、現在利用しているデザインテンプレートで存在しないテンプレートは、デフォルトを参照しにいくなどが必要
• 利用しているテンプレートがデフォルトのアップデートの影響をうけてしまわないような作りが必要（本体のバージョンアップで変わる可能性のあるjQueryはデザインテンプレートに同梱された物を使うなど）

探索順位案

改善したい点は数多く有りますが、ひとつだけ挙げるならこれです。

ページクラスからビジネスロジックを切り離し、処理の対象毎にまとめて Model クラスとして再構築します。

また、従来からのコードで Model と同様の働きをするクラスを Model として再定義します。
例）
SC_Product → ¥Model¥Product¥Product
SC_Helper_Category → ¥Model¥Product¥Category
SC_Helper_Purchase → ¥Model¥Order¥Order
SC_Customer → ¥Model¥Customer¥Customer

テンプレートエンジンをそもそも使うかどうか、
使うとすれば何を使うか

eccube_install.sh mysql でインストールした場合に、 DBの文字エンコーディングが laten1 等になっていると文字化けしてしまう。

明示的に utf8 を指定した方が良い

下記イメージで管理画面を実装する

• システムに関する項目はすべて「設定」タブにいれる
• レスポンシブ対応

認証

OAuth 2.0？SAML？要検討

通信方式(REST)

HTTP メソッドをリソースの操作とする。

• POST：create
• GET：read
• PUT：update
• DELETE：delete

URL

例）/api/[リソース]/

• 顧客IDの一覧を取得する

    GET ~/api/customer/

• 新規の顧客データを作成する

    POST ~/api/customer/

• [DB系] ※要検討
  • /api/db/customer/
  • /api/db/product/
  • /api/db/order/
• [振る舞い系] ※要検討
  • カート情報確認
  • カートに入れる
  • カート削除
  • お届け先の指定
  • 支払方法、お届け日時の指定
  • 購入情報最終確認
  • ログイン /api/login/
  • ログアウト /api/logout/
  • メール送信

パラメータ

パラメータはJSON形式で渡す。

GETパラメータ例

~/api/customer/?json=
{
    include: [ "id", "name", "*"],      // 取得するカラム
    filter: {
        "name": ["test", "aaaa", "test example"],          // name に test と example を両方含む
          // -> where name = test or name = aaaa or (name = test and name = expamle)
        "kana": ["hoge"]
          // -> and kana = "hoge"
    },
    sort: {"id":"asc", "create_date":"desc"}, 
    limit: 50,
    offset: 100,
}

POSTパラメータ例

~/api/customer/?json=
{
    include: [ {"name":"ほげほげ"}, {"kana":"ホゲホゲ"}]
}

PUTパラメータ例

~/api/customer/?json=
{
    filter: {
        "id": "1",
        "name": "test example",          // name に test と example を両方含む
        "name": [ "1test", "example" ]   // name が test または example に完全一致
    },
    include: [ {"name":"ほげほげ"}, {"kana":"ホゲホゲ"}]
}

DELETEパラメータ例

~/api/customer/?json=
{
    filter: {
        "id": "1",
        "name": "test example",          // name に test と example を両方含む
        "name": [ "1test", "example" ]   // name が test または example に完全一致
    }
}

レスポンス

パラメータはJSON形式で渡す。

• HTTPステータスコード「200,201」：OK (POSTの場合のみ、201)
• HTTPステータスコード「200,201以外」：NG

Security Bug fixされているバージョンにあげる

see https://scrutinizer-ci.com/g/EC-CUBE/ec-cube/issues/eccube-3.0.0-beta/files/composer.lock?orderField=path&order=asc#inspectioncomment-684225486

DocumentとしてFIXしてしまう前に、現在開発しているプラグインのフックポイントと、その実行順序について、覚書程度に記載します。

フックポイントの命名規則

eccube.event.*.(before|after|finish)

現時点で、自動生成もしくは定義されているフックポイント一覧

• eccube.event.app.before
• eccube.event.app.after
• eccube.event.controller.ROUTE.before
• eccube.event.controller.ROUTE.after
• eccube.event.controller.ROUTE.finish
• eccube.event.render.before
  • $app['view']->render() のときにEventが走る。
  • 引数のEventObjectを利用することで、ソースコードを自由に触れる用にしてある

ROUTE は、 $request->attributes->get('_route') で取得できる、ルーティング名
->bind('ここ')

実行順序

1. eccube.event.app.before
2. eccube.event.controller.ROUTE.before
3. eccube.event.render.before
4. eccube.event.controller.ROUTE.after
5. eccube.event.app.after
6. eccube.event.controller.ROUTE.finish

同一のフックポイントを利用している場合は、EventSubscriberで定義した優先順位による

これから実装するところ

• 各Form\Type

2.13 では、2つありましたが、まとめた方が良いのかなと。

• docs\テーブル定義書(EC-CUBE2.13dev).xlsx
• docs\table_definition.xls

個人的には、前者は Excel 方眼紙で勝手が悪かったので、最近は後者を重宝しています。

今後の保守方針に関して、Excel 直書きなのか、ツール生成なのかといった当たりも明確にしたほうが良いように感じます。(docs\ER-D\README.md みたいに、なっていると分かりやすいですね。)

EC-CUBE 上の用語との差異も散見するので、統一していくのも必要かと考えます。

合わせて、html\install\sql\comment_set_pgsql_2.13.sql の保守も課題でしょうか。
#22 あたりとも関わりますかね。

ログの処理を monolog を用いて行いましょう。
https://github.com/Seldaek/monolog

ルーティング機能やDBマイグレーション機能など、これだけの大幅な変更を加えるのであれば、いっそのことフレームワークの利用を検討してみては如何でしょうか。

今まで、EC-CUBEではDBのスキーマを変更した際にmigrationを作成していませんでしたが、今後は何からの形でcommitに含めませんか？

バージョンアップしやすいように開発することも安全なウェブシステムに重要ではないでしょうか。

ざっと作ったため、管理画面にログインできない状態です。
近々直しますので、開発されている方はそれまでeccube_install.shでインストールしてください。

• 実装時には下記３つのファイルを使用する
  • html/index.php：html/router.phpを読み込むのみ
  • html/router.php：ルーターのロジック（定義ファイル以外読み込まない）
  • html/routes.php：ルーティング定義ファイル
• URLをparseし、対応したclassを呼び出す
• html/routes.phpの定義は以下の通り

$arrMaps = array(
    array(
        'method' => 'GET|POST',
        'path'   => '/',
        'dir'    => '',
        'class'  => 'index'
    ),
    array(
        'method' => 'GET|POST',
        'path'   => '/products/detail',
        'dir'    => 'products',
        'class'  => 'detail'
    ),
    array(
        'method' => 'GET|POST',
        'path'   => '/admin/',
        'dir'    => 'admin',
        'class'  => 'index'
    ),
    array(
        'method' => 'GET|POST',
        'path'   => '/admin/login',
        'dir'    => 'admin',
        'class'  => 'login'
    ),
);

商品詳細ページにて「カートに入れる」ボタンを押すとページがみつかりません。

.gitignore を作成します。

現在、歴史的経緯からとお見受けしますが、testとtestsに分かれておりわかりにくいと思います。
テストのカバレッジもあまり良くない状況だと思います。

こちらについて、何か整備指針などはありますでしょうか。

• test.local ではなく eccube-vagrant に合わせる、もしくは localhost のように汎用的なホスト名とする、もしくは必須入力とする。
  • #62 のようなトラブルに苦しむ人がいるので。。。
• HTTP_URL の最後に / が無い

AppVoyer だとテストがこけるのでappvoyer.ymlの修正が必要です。

参考
https://ci.appveyor.com/project/ttsuru/ec-cube

action()内では、カウンタ変数以外のローカル変数を許容しない
必ず、クラス変数とすること

https://www.uploady.com/#!/download/IPRHKtYjq4h/Uz81izfLasnDJziu

βリリースまでは、開発スピードを重視し、以下をテスト基準にしようと思いますが、いかがでしょうか？

特に、src\Eccube\Service\は、ビジネスロジックがほぼすべて集約されるため、最重要と考えています。
そのため、src\Eccube\Service\以下は、カバレッジ100%にしていきたいです。

• 疎通確認（Routing）テスト
  • 全正常系/異常系を網羅
• src\Eccube\Service\に属するClassの単体・機能テスト
  • 単体テスト100%
  • 機能テスト100%
• src\Eccube\Form\Type\に属するClassの機能テスト
  • Validationチェック
• src\Eccube\Plugin\に属するClassの単体・機能テスト
  • Plugin詳細が決まり次第

上記に含まれていない、

• src\Eccube\Controller\
  • ビジネスロジックを持たせないように作成していくため
• src\Eccube\View\
  • カスタマイズ前提で、テストされている意味が薄いため
    以上を理由に、テストをマストにしていません。

βリリース以降では、上で挙げたもの以外も対象にしていきたいと思います。

👍 や 👎 だけでもコメントいただけると判断しやすいです。

dtb_products_class.product_type_id
初期で使われていない0が初期値。データ移行で不正なデータが発生して発覚。とりあえず削除する。1でも良い気もする。

今後のDirectory Structureについて、何か指針はありますでしょうか。
大幅に構造が変わるようですので、わかりやすく、トレンドな感じにまとめてはいかがでしょうか。

前々からやりたかった事で、やれと言われたのでこの機会にやっちゃいます。
前に合宿でとりあえず商品一覧動くまでやったのがコレです。
chihiro-adachi#2

データ構造の柔軟性と、検索や表示の高速化を実現するために、concrete5と同じ様な仕組みにしたいと思っています。（ こんなんです > https://github.com/concrete5/concrete5-5.7.0/blob/develop/web/concrete/src/Page/PageList.php ）
ざっくり言うと、正規化しまくって検索用のインデックステーブルを作る感じです。
これにより、管理画面側に商品属性の管理機能が必要になります。

それと、現在のdtb_produtsは商品マスタではなく、dtb_product_classが商品マスタに該当するという認識があるので、
dtb_product_class > dtb_produts
にしています。

とりあえずこの方針でやって良いとは言われたのですが、皆さんのご意見も聞きたいので、よろしくお願いします。

• 環境毎に調整が必要な値のデフォルト値の修正汎用的なものにする
• test.local 等ではなく eccube-vagrant に合わせるか、localhost のように汎用的なホスト名とする、もしくは必須入力とする。DB_NAME等も同様
• エラーがでている
  • chmod: cannot access `./src/Eccube/page': そのようなファイルやディレクトリはありません
  • ERROR: リレーション"dtb_bloc_bloc_id_seq"は存在しません
    行 1: SELECT SETVAL ('dtb_bloc_bloc_id_seq', 10000);
  • ERROR: リレーション"dtb_pagelayout_page_id_seq"は存在しません
    行 1: SELECT SETVAL ('dtb_pagelayout_page_id_seq', 10000);
    他。
• 一番上の使い方のコメントが間違っている。

まずは 2.13.x ベースのものを追加

購入フローから注文完了までのビジネスロジックを @chihiro-adachi と二人で進めていってます。

SC_XXXX系の登場人物が多いため乗せ換えが難しく、なおかつ、今のロジックのまま開発を進めるより、オブジェクト設計・フロー設計を合わせて見なおしたほうがいいと判断したため、リファクタ込で進めていっております。

具体的には、以下の作成をしています。

• CartService
  • カートセッションの管理クラス
• OrderService
  • 注文まわりの管理クラス

乗せ換えフェーズの原則から外れるイレギュラーな対応となるため、周知の意味で取り急ぎIssueをたてさせていただきます。

購入フローのステップを短縮化する。

eccube_install.shを環境に合わせて編集し、スクリプトを実行したにもかかわらず、
http://xxx.xxx.xxx/
（eccube_install.shに記述したURL）にアクセスすると、http://test.local/にアクセスしてしまい、エラーとなってしまします。
他に修正すべきファイルがあるのでしょうか？

EC-CUBE3β版のインストールを行いましたが404エラーとなりadminが表示されません。
http://[URL]/html/adminと入力しています。
商品購入のトップ画面は表示されます。
html/adminを認識していないようですが、インストールを失敗しているのでしょうか？
html/adminの中はload_module_config.php　load_plugin_config.php　require.php　cssとなっています。
パスか環境設定の問題だと思うのですが、対処方法があればご教示下さい。
よろしくお願いします。
なお、環境は下記の通りです。
centOS7
apache 2.4.6
PHP 5.4.16
MariaDB

取り急ぎ把握したいのは、PostgreSQL のバージョンなのですが、諸々どこかにまとまっていましたっけ?

インストールマニュアルがないため、作成する。

• Git版(composer利用する)
• Package版(.tar.gz, .zip)

一般的なRESTful URLでは / をつけない方が多いと思いますが、SymfonyのSecurity を使った際に /admin のみだと /adminxxx など前方一致となるため、 2系の index.php の省略の場合には後ろの / までをURLとした方が良いかと思います。