最新EC-CUBE3.0活用虎の巻~プラグイン徹底解剖

第3回 EC-CUBE3.0のプラグイン仕様を徹底解説!

この記事を読むのに必要な時間:およそ 2 分

ここまで2回にわたり,EC-CUBE3.0の特徴やプラグインの利用方法を解説してきました。今回から,EC-CUBE3.0とプラグインの内部構造に迫っていきます。ぜひ本記事を参考に,プラグインの開発にチャレンジしてみてください。

EC-CUBE3.0の内部構造

第1回で触れたとおり,EC-CUBE3.0では,SilexというSymfonyComponentsベースのマクロフレームワークが採用されました。その他にも,データベースアクセスにはDoctrineORM,テンプレートエンジンにはTwigが採用されています。このようなフレームワーク採用により,ディレクトリ構成や処理の流れがどのように変わったか,見ていきます。

まずディレクトリ構成を解説します。配布されているEC-CUBEのアーカイブを解凍すると,src,app,htmlの3つのディレクトリが展開されていることがわかります。それぞれのディレクトリの中身は以下の通りです。

  • src:EC-CUBEのプログラム本体が配置されている
  • app:設定ファイルやログファイルなどが配置されている
  • html:画像ファイルやCSS,Javascriptなどのリソースファイルが配置されている

src配下がEC-CUBEのプログラムが配置されているディレクトリです。src配下を見ると,さまざまなディレクトリが格納されています。

ディレクトリ名機能名
Eccube直下ベースとなるクラスのApplication.phpが存在し,必ずこのクラスから実行される
ApplicationApplication.phpの親クラス
Commandコマンドツール用クラス
Common共通クラス
Controllerコントローラクラス
ControllerProviderルーティング定義用クラス
DoctrineDoctrine拡張クラス
Entityエンティティクラス
Eventイベント関連クラス
EventListenerイベント関連クラス
Exception業務エラー関連クラス
Formフォームタイプクラス
Pluginプラグイン関連クラス
Repositoryレポジトリクラス
ResourceDoctrine用dcmファイルやtwigファイルなど
Securityセキュリティ関連クラス
Serviceサービスクラス
ServiceProviderDI定義寒冷
TwigTwig拡張
Util共通関数クラス

EC-CUBE3のプラグインを作ってみよう!より引用

かなりたくさんのディレクトリがありますが,EC-CUBE3.0の処理の流れを追いかけるうえでは「Controller」「ControllerProvider」「Form」「Repository」を押さえておけば理解は容易かと思います。

それでは,ページにアクセスして,画面が表示されるまでの処理流れを見ていきましょう。

  1. ブラウザからリクエスト送信
  2. ルーティング定義により,アクセスされたURLとコントローラをマッピング
  3. コントローラのメソッド呼び出し
  4. フォームタイプの入力値マッピング及びバリデーション
  5. レポジトリ(Doctine)でのデータベースアクセス
  6. ビュー(Twig)のレンダリング
  7. ブラウザへレスポンス返却

少し難しい用語がでてきますが,図にすると以下のようになります。

画面が表示されるまでの処理の流れ

画面が表示されるまでの処理の流れ

プラグインでできること

EC-CUBE3.0の全体像を抑えたところで,本題のプラグインの仕様に踏み込んでいきましょう。プラグインでできることは,大きく分けて以下の2点です。

  • 新規ページの作成
  • 既存機能の変更・拡張

まず,新規ページの作成については,かなり容易に作成が可能です。EC-CUBE3.0では,「ルーティング」という仕組みが新たに追加されています。「ルーティング」とは,アクセスされたURLとコントローラクラスを紐付ける仕組みで,その定義はControllerProviderクラスに定義されています。たとえば商品一覧ページであれば,以下のように定義されています。

$c->match('/products/list', '\Eccube\Controller\ProductController::index')->bind('product_list');

これは,「/products/list」というURLでアクセスされた際に,ProductControllerのindexメソッドが呼び出される,という意味になります。このルーティング定義はプラグインから拡張可能となっているため,ルーティング定義を追加するだけで,EC-CUBE本体と同様の構造で新規ページを作成できます。

次に,既存機能の変更・拡張について見ていきます。アプリケーションの処理の前後や特定の処理の前後に処理を介入することができ,以下の拡張が可能です。

  • コントローラの前後での処理介入
  • 入力フォームの拡張
  • ビューの書き換え

このような処理の介入について,詳しく見ていきたいと思います。

コントローラの前後での処理介入

コントローラの開始時や終了時に処理を介入するには,「フックポイント」を利用します。「フックポイント」はすべてのコントローラで実行するか,コントローラを指定して実行するか定義することができます。また,実行タイミングはbefore/after/finishの3種が用意されています。before/afterは文字通り,コントローラの開始時,終了時を指します。finishは,終了時に実行されますが,ファイルダウンロード処理時のテンポラリファイルの削除処理など,特殊な処理でしか使用しないでしょう。

コントローラの前後での処理

コントローラの前後での処理

入力フォームの拡張

管理画面の既存機能に入力項目を追加する,といった拡張はよくあるユースケースですが,既存の入力フォームの拡張も容易にできるよう,FormExtensionという拡張方法が提供されています。EC-CUBE3.0では入力フォームの定義やバリデーションは,FormTypeクラスで定義されています。すべてのFormTypeにはForm名が定義されており,Formを継承する形で拡張が可能です。

入力フォームの拡張

入力フォームの拡張

ビューの書き換え

描画されるコンテンツや,ヘッダを書き換えることができます。画面上にボタンやフォームの追加など,HTMLの変更が可能となっています。また,HTTPヘッダも変更することが可能であり,たとえば別ページへリダイレクトさせるといった処理も可能です。

ビューの書き換え

ビューの書き換え

いかがでしたでしょうか。今回はEC-CUBE3.0の全体構造やプラグイン仕様の概要を解説し,具体的な記述方法は省略しましたが,より詳しく知りたい場合は,EC-CUBE公式サイトより提供されているプラグイン仕様(PDF)を参照いただければと思います。また,Githubのレポジトリでもプラグインのソースコードが公開されているため,参考にしてみてください。

次回は,ロックオンより提供されているサンプルプラグインのソースコードを追いながら,より深くプラグインの実装方法について解説をしていきます。

著者プロフィール

馮富久(ふぉんとみひさ)

株式会社技術評論社クロスメディア事業部電子出版推進室室長。

1975年生まれ。横浜市出身。1999年4月株式会社技術評論社に入社。入社後から『Software Design』編集部に配属され,2004年1月に編集長へ就任。同2004年9月に『Web Site Expert』を立ち上げ,同誌編集長に就任,現在に至る。その後,2008年9月に設立したクロスメディア事業部に配属。現在,電子書籍を考える出版社の会の事務局長やWebSig 24/7のモデレーターを務める。過去にIPAオープンソースデータベースワーキンググループ委員やアックゼロヨン・アワード他各賞審査員などの経験を持つ。

Twitte ID:tomihisa(http://twitter.com/tomihisa/

コメント

コメントの記入