Scala Liftの教訓 - Qiita
Scala LiftのView Firstの思想に刺激され紹介記事を書き、実際に使ってみてたどり着いたのは、これはちょっと使えないなという悲しい結末・・・とはあの頃予想できただろうか(いや、できない)。 正月とこれまで幾日かの土日を費やしたどり着いた結論は以下の通りだ。 結論 UIから作るViewFirstで開発を行いたい！場合、Angular.jsやKnockout.jsのようなフレームワークを導入し画面側から開発を行い、Model設計(JavaScriptクラス)が固まってきたらサーバーサイドで永続化の処理を実装するのがベストだ。 ロジック混入を回避する場合はAngular.jsならDirective、Knockout.jsでも普通にtemplateを使えば隠蔽可能だ(モジュール化をきちんとやるならAngular.jsの方がカスタマイズ性は高い)。 JavaScriptフレームワークの
Railsの逆を行く、デザイナと開発者が協力するためのScala Liftフレームワーク - Qiita
最近のフレームワーク、っていうとどれもRailsと似たような感じで実装言語が違うだけでしょ？という感じですが、Liftはそんな中完全に逆を行ってます。 その思想は他の言語でも通用するはずなので、ぜひScalaなんぞ知らんという方も読んでいただければと思います。 Liftの特徴 公式な特徴はホームページに記載されていますが、個人的にプッシュしたいのは以下点です。これらは、Templatingに詳しく書かれています(日本語訳)。 1 デザイナフレンドリー 2 コントローラーがない 3 速い デザイナフレンドリー 自分の手元にあるerbやらjspやらasp(chtml/vbhtml)やらのファイルを見て、これをサーバーサイド側の言語を知らない人間に手渡せるか？と考えたときYesと言える人はどれくらいいるでしょうか。 それらのファイルにはそこそこコードが入り組んでいて、特にRailsの場合顕著です
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
