Capter5

写経しながら進める。

Capter4で立てた計画に基づいてModel→View→Controllerの順に実装を行っていく。

entityとそれに対応するサービスを作っていく。ココらへんの構成は割りとありふれた感じですね。ただやっぱりpublicなフィールドにはなんとも言えない感じになりますが自分しか使わないクラスなんだし気にしなくていいのかなと。

ここで使っているOptionはPlay Frameworkが用意しているplay.libs.Fクラスに含まれているJavaでOptinを扱うための擬似的なOptionになります。

ScalaのOptionを借りてきたような感じなんですかね。

Scalaは全く書いた事ないわけですがなんとなく書いてある事は分かるもんですね。

同時進行中のOcamlのOptionだとこんなのですと。

type `a option = Some of `a | None

サクっとググった限りではOptionがどの言語発なのかよくわからなかったけどひじょーに便利ですね。バンザイ。

Ebeanが2.3からサポート外れるとの記述がありますが、個人的にJPAやHibernateのような勝手にアレコレやってくれるのはあまり好きではなく、素直にクエリを実行してくれと思ってしまう派です(過去に関わったのがアレすぎたのが原因だと思いますが)。

.NETのDapper移植のDapper4jとかあれば一番いいんですけど。

各ビューの設計方針やヘルパー、タグの使い分けなど。

またテンプレート作成時にScalaのコードの説明をぼちぼち加えていく感じ。疎になり過ぎないようにかつ再利用性を高めるような設計は経験を積んでいくしかないんでしょうね。ヘルパー、タグなんかは上手く作ればプロジェクト単位で使いまわせる資産になる一方で、最初からアレコレ狙うとつらそう。

Scalaのトレイトなるものの説明がちょっとありますが

トレイトについては、第9章で触れますが、わかりやすく一言で言うと、実装を持てるインターフェースのようなものです。

abstractよりゆるふわな感じ？

ヘルパーの部分ではなんでこれがダメで

@(date:java.util.Date)
@defining(models.view.DateFormatter.formatDefaultDate(date)) { 
    d =>  <span class="myDate">@d</span>
}

これがOK？

@(date:java.util.Date)
@defining(models.view.DateFormatter.formatDefaultDate(date)) { d =>
    <span class="myDate">@d</span>
}

@の範囲が問題？

IDEを使っていると補完の都合上、実装順序をある程度前後した方がよさげ。けどあいかわらずrender()の呼び出しが赤くなるのが嫌な感じ。

ここまでの作業で一応動くものになった。

f:id:ebifly10:20140618230644p:plain

なんかチガウ...。

空飛ぶ