framework

Aura:FilterとFormでValidation

by codechord. 0 Comments

ちょっとしたAjax系のFormの実装をする必要があって、
一枚ペラっと作ってもイイんだけど、せっかくだし今風に作ってみようと思い、Auraに手を出した。

Formのためだけに、Wordpress使うのもなんだし、LaravelやSymfony使うのもFatすぎるかなって感じていて。
Auraはフルスタックのフレームワークではなく、必要なComponentをとっつけて組み立てるという感じ。

理解の仕方は、次の順
日本語ドキュメントがあるので、ざっくりはわかる。
・一つ一つのComponentが軽量でソースを追っかけるのも比較的簡単。
・同様に、それぞれがのReadmeドキュメントが整ってる印象。

https://github.com/auraphp
https://github.com/friendsofaura
今回サンプルとして、htmlのフォームでPOSTした内容をバリデーションチェック加えて、json形式で何らか返すというものを
以下の2パターンで作った。それぞれは同じ結果を返す。

・A: Filterをaura/filterを直接使う。(github)
・B: aura/input/Formの継承クラスを作成し、Form内でfilterを行う。(github)

基本

/vendor/auraの中身で、重要そうなのは、web-kernelあたりのよう。
ここでrouter、dispatcher、あとwebコンポーネントにある、RequestとResponseとかが、定義される感じ。

アプリケーションは、/config/Common.phpにかいていく。なお、/config/_env.phpにて、環境の設定を変更をすることで、

  • /config/Dev.php
  • /config/Prod.php
  • /config/Test.php

と、環境別に動作を切り替えれることが出来る。/config/Common.phpは、_env.phpの設定にかかわらず全てにおいて実行される。

DI

関連するサービスをsetし、必要時に、getして使う。

 $di->set(<サービス名>,$di->lazyNew());
 $service = $di->get(<サービス名>);

ルーティングとディスパッチャ

$router->add()でルーティングを指定して、$dispatcher->setObject()のクロージャで、ルーティングの処理をする。

$router->add(, );
$dispatcher->setObject(, function () use ($di) {
  // ここに処理
});

バリデーションチェック

Aura/Filterを追加する必要がある。Aura/inputも。必要に応じてAura/htmlも追加。

  • HTMLテンプレート書くなら、次のバンドルをcomposerに追加する。
    composer require foa/html-view-bundle
  • フォーム書くなら、次のバンドルをcomposerに追加する。
    composer require foa/filter-input-bundle

さて、説明がうまく出来ないので、以下のA、Bの場合とで、サンプルソースを見比べて欲しい。
/form.htmlの静的フォームから/sendにPOST送信され、フィルタのかけ、Jsonを返すのだが、Bの場合だけDIを使った形となっている。

A:Filterだけの場合
https://github.com/tomothumb/Sample-Aula-validation/blob/5e8dd23b450140ab4f2fe55ac7a0b399dc2bedb3/config/Common.php
Dispacharの中に書いていく。

B: Fromを利用する場合
https://github.com/tomothumb/Sample-Aula-validation/blob/master/config/Common.php
/src/App/From/Contact.phpを追加し、Formの要素とバリデーションの内容を記述する。

違いをGistに書いた。(わかりにくい。。。)

設計方法学ぼうとおもってたのに、いつのまにか、アプリケーションの書き方/使い方を学んでいる自分がいる。。。

同じことをSilexとSlimでも今度やってみよう。

ECCUBE3とSymfonyとSilexの歩き方

by codechord. 0 Comments

Photo-12-12-15,-12-06-20-AM

日付変わっちゃいました・・・
2015年ECCUBE アドベントカレンダー23日目の記事です。写真はECCUBE開発合宿の深夜の1コマ。

当初、作ったプラグインの案内でもしようかと思ったのですが、バグだらけで改善作業中なので、自分がECcubeを理解していく中で(まだまだわかってないですが)、自分なりのベストプラクティスを、これからECCUBEの開発を始めるヒトに向けて共有したいと思います。
ちなみに、バグだらけのプラグインはgithubベースでメンテするというか、メンテフリーで行く予定なので、自由にパクって下さい。
ECCUBE3-InfiniteScroll」「MECCUBE3-Masonry」「ECCUBE3-Loveit」(3つありますが、内容似てまして、松竹梅的な。)

思ってたのとなんか違う。

まず、私個人としては、Laravelは半年弱ほど触った程度。
LaravelはSymfonyベース、ECCUBEはSilexベース、そのSilexはSymfonyベース、だからきっとなんとなくわかるはずと思ってたんですが、いざ蓋を開けてみると、「これ、思ってたんと違う。。」というのが正直な感想。

Symfonyを理解していないからか?と、そう考え、ECCUBEの開発合宿へ参加したついでに、たまたまその翌日、東京はメルカリさんで開かれたsymfony meetupに寄ってきました。
つい先日、待望のsymfony本「基本からしっかり学ぶ Symfony2入門」の出版されたけども、その著者が登壇されるということだったので、行かなきゃとい思いまして、毎度のことながらスケジュールつめこんで。

Symfonyを学ぶことは近道。

ECCUBEを始め、最近は著名なCMSやフレームワークがこぞってSymfonyを採用しはじめていますが、なぜSymfonyが選ばれるか。なぜSymfonyが王道なのか。そういった内容を話されていました。(そのスライドはこちら⇒ Symfonyを選ぶ理由とその他の話 )

CakePHPでも、Laravelでも、それぞれのフレームワークでCakePHP Way、Laravel Wayみたいな◯◯Wayというベストプラクティスや強い主張があったりするけど、Symfonyというのは、主張してこないフレームワークであると。自分流にアレンジしやすいとのこと。

主張してこないとはどういうことかというと、Symfonyのコアが担うのは、
「リクエストを受け取り⇒レスポンスを返す」
というところ。つまりは、Webアプリケーションの根本的な所を学ぶことができると。

王道を知ることは、今後他のフレームワークを理解するうえでも、それぞれの◯◯ Wayの解釈ができるようになりますよ、とそういった内容でした。

(※ちなみに、Symfonyの日本語ドキュメントのサイトは遅れているようで、翻訳ついていくのは諦め気味とおっしゃっておられました。)

Symfonyの基礎をわかるとどうなる?

symfony本「基本からしっかり学ぶ Symfony2入門」全300Pぐらいで、早速ですが簡単な所は読みました。初期の構想から発売まで二年半ぐらいとおっしゃっておられたような。書籍の構成としては、

  • フレームワークとはなんぞや
  • Symfonyとはなんぞや。
  • デバッグバーの使い方
  • Routing
  • Controller
  • View (Twig)
  • Entity (Doctrine)
  • Repository
  • Form
  • Validation
  • メール(Swiftmail)
  • 機能の拡張
  • フィクスチャ
  • Console拡張
  • API実装
  • サービスプロバイダ
  • テスト

が順に解りやすく落とし込まれてあり、読み進め、実際に手を動かしながら、一つのWEBアプリケーションができます。Symfonyの基礎が中盤ぐらいまででわかります。後半で、サービスプロバイダの解説がされてありますが、ここを理解することがSymfonyおじさんになる手段であり、みながSymfonyを採用する肝のようです。ここまで読みきれてません、まぁ正直難しいです。

ECCUBEおじさんになるためには

先に述べたとおり、基本的な所を読了するだけで、ECCUBEのディレクトリ構造がざっくり理解できるようになります。
するとまぁ、ECCUBEとSymfonyとの違いがなんとなくわかりはじめます。

Symfonyは個性を主張してこないと述べましたが、Symfonyのチュートリアル的なものをしていると、アノテーションとか、手軽だけど、なんか魔法ばっかり。思っきり個性を主張してきます。。。(目をつぶります)

このせいで、Doctrineでもフォームでも何でも、ECCubeが吐くエラーメッセージの解決策をググりますと、概ね、Stack Overflow様がSymfonyの解決するための黒魔法を教えてきます。ECCUBEではこの魔法が全く役に立たずハマります。

そこで、Symfony本に目を通しておきますと、ホグワーツ魔法学校に通ったようなものですから、この先生の言ってることは、こう読み替えればよいのかとか、Silexの領域だなとか、ほんの少し見えてくるようになります。
で、最後にSilexやDoctrine、Symfonyのドキュメンテーションへと理解を深めていく旅に始まります。

Silexにどっぷりは必要?

おそらく、ECCUBEを深く知る上では、

  • Symfonyの基礎を把握する
    ⇒必要に応じてSilexのドキュメントを見る

という流れではありますが、Silexのドキュメントもなかなかしんどいです。
ECサイト作成程度の話であれば、Silexには触れず、

  • Symfonyの基礎を把握する
    ⇒ECCUBEのコアのコードからパクる。
    ⇒必要に応じてSilexのドキュメント

というのがベスト・プラクティスじゃないかなと思っています。といいますのも、Symfony基礎がわかるとディレクトリ構造がわかるので、コードのたどり方がなんとなくわかってきて、ECCUBEコアに、ピンポイントで似た例がでてくるのがほとんど。Silexのドキュメント見るより手っ取り早いと感じるからです。

コア開発者になるなら、SilexもSymfonyサービスプロバイダもしっかり理解してください。ということになるんだと思います。

さいごに

ECcubeの話というより、Symfonyの話がほとんどになってしまいました。
最後になりますが、ECCUBEはSilexベースですが、Symfonyかじらず、いきなりSilexから入っちゃうと遠回りになると思うので。まずは王道からと、オススメしつつ、アドベントカレンダーをバトンタッチしたいと思います。

最後になりますが、Symfonyを初学者向けソースを、Symfony meetupで知った部分貼っていきます。
参考になれば幸いです。

Sublime Text 2とCtagsの組み合わせがすごい。開発スピードUP[Mac版]

by codechord. 0 Comments

Sublime Text 2では、Ctagsプラグインを使うことによって、コードナビゲーション(Class/Functionが定義されてるところへジャンプ)できるようになります。
これ、僕のベスト10には入ってくる、お気に入りプラグインです。

コーディング中にふとClassやFunctionの動作を知りたくなった時にいちいちFunction名をサイト内検索したり、ドキュメントサイトを開いて探さなくても、キーバインドで瞬時にそのClass/Functionが定義されてるところへジャンプして確認できると。
(こういった機能のこと、コードナビゲーションとかコードナビゲートと呼ばれているようだ。NetbeansやEclipseなんかでは標準でついてる機能なのかな。Sublime Text 2では標準で付いていない。)
WordPressのテーマ、プラグイン開発などの小中規模の開発や、その他CMSやフレームワークを利用する際、ドキュメントを見るより、コードを見たほうが早く解決できることも多いので、効率的に開発できるようになります。

と、文章で記述しても伝わりにくいので、英語ですが動画見てもらった方がイメージをつかみやすいかなと。(4:10~6:00ぐらいまで)
YouTube Preview Image

次の上2つについては以前紹介しましたが、加えてコードナビゲーション機能があると、軽量で高機能のエディタへと進化します。

  1. FTPが使え、保存と同時にアップロードもできる。
  2. Sass/SCSSのコンパイルが簡単。
  3. コードナビゲーションが使える。(←これ)

プラグインは以前からインストールしてマニュアル通り設定していたものの、どうもSublime Text 2からCtagsをリビルドできない状態でして、Terminalから.Ctagsファイルを作っていたのですが、エディタ設定を見なおしたらすんなりSublime Text 2からCtagsをリビルドできるようになりましたので、共有したいとおもいます。(Macでの手順です)

続きを読む »