大なごやJS vol.5 (#daiNagoyaJS)
-
girigiribauer
- 2207
- 0
- 0
- 0
-
- いいね！0
girigiribauer
@girigiribauer
フレームワークの必要性について、Spine.jsの方は比較的MVCがきっちり分かれてる印象、ページ遷移によっても状態を保持するステートフルなところから、フレームワークが必要なのでは #daiNagoyaJS
2013-02-23 14:22:49
girigiribauer
@girigiribauer
ステートレス前提の従来の手法ではうまくいかない、うまいやり方はないか？MVC使えるんじゃないか、MVCは基本的にGUIアプリケーション、つまりユーザーと対話するとき、GUIアプリケーションを作るための手法 #daiNagoyaJS
2013-02-23 14:25:42
girigiribauer
@girigiribauer
プレゼンテーションロジック、見た目に関するところ、ビジネスロジック、アプリケーションの本質的な部分、つまりGUIを考えないときも含む #daiNagoyaJS
2013-02-23 14:26:50
girigiribauer
@girigiribauer
ビジネスロジックはModel, プレゼンテーションはView, Controllerが担当、その中でもControllerはユーザーの入力などを適切に処理する、ViewはUIの外観を制御する役割 #daiNagoyaJS
2013-02-23 14:28:00
girigiribauer
@girigiribauer
JSでのViewの役割、直接めにふれるところはHTML、役割としてHTMLを生成する必要がある、生成に関わるロジックも含める、基本的にロジックを含めない方がいいと言われているが、HTML生成に使うものはこちらに含めた方がいいのでは？ #daiNagoyaJS
2013-02-23 14:29:06
girigiribauer
@girigiribauer
Hamlを使う、HTMLを簡潔に書く、簡単なロジックが書ける、基本的にHTMLを生成するので、書ける人なら大体わかるようになってる、部品ごとにファイルを分けることができ、メンテナンス性、再利用性が高まる、規模がでかくなると大事 #daiNagoyaJS
2013-02-23 14:32:13
girigiribauer
@girigiribauer
Hamlは協力なテンプレートエンジンなので、あらかじめ使えるものは限定させておく、でないとviewが大変なことになる、指針としては関数に渡す引数はJSON形式のみ許すようにしている #daiNagoyaJS
2013-02-23 14:38:30
girigiribauer
@girigiribauer
逆にview内で勝手にメソッドを作ったりはしない、HTMLの生成に必要なもののみ、viewをHamlにしたことで、プログラマー以外の人でも分業できるので、ある程度構造を変えてしまっても対応できる #daiNagoyaJS
2013-02-23 14:39:50
girigiribauer
@girigiribauer
Hamlのソースのヘッダーにコメントを書いておくと、後からツールを使ってドキュメントを作れる、Yuidocの例でデモ #daiNagoyaJS
2013-02-23 14:40:33
Yutaro HIGASHI
@suica_versa
#daiNagoyaJS マークアップやる人がHaml使ってくれるならいいけど、とりあえずダミーのデータで生のHTML書くほうが今のところ多いからHaml使う機会なかなかないなぁ
2013-02-23 14:41:53
girigiribauer
@girigiribauer
ドキュメントを生成することで、分業もよりしやすくなるのでは？ またJSONのデータは自由に作れちゃうので、厳密にデータをやりとりしたいときに、JSONに制限をつける #daiNagoyaJS
2013-02-23 14:42:24
girigiribauer
@girigiribauer
viewにHamlを使うメリット、HTMLが分かれば分業できる、どんどんインクルードの形で別のHamlを読み込むので、全体の構造が分かる、関数化して細かく分割できることで、再利用性が高まる、基本的に1つのファイルになる、 #daiNagoyaJS
2013-02-23 14:44:24