#ついでにと言ってはなんですが、bodyで(file filename)以外でも:content-typeの指定が使えるようにして欲しいです。
#makiki.scm変更pushしましたー。respond/ngではcontent-typeオーバライドできないけど出来た方がいいかな。
#統一性のためにできるようにした。
#おお。ありがとうございます!
#ところで、テストってどうやってます? 最初モックアップの request オブジェクトを作ってハンドラに渡すとかすればいいかと思ったんですが、それもちょっと難しそうなので、テストの対象をうまく切り分けられれば良さそうな気がするんですが。
#makikiではまだあんまり考えてないんですが、前にkahuaの発展形絡みで何か考えてたような… あっそうだ。テストの結果をチェックするのに、xmlなりhtmlなりの最終系でやるんじゃなくて、その前の抽象的な表現でやろうとしてたんだ。最終系 = render(ロジックのアウトプット, テンプレート) と考えて、ロジックはロジックだけでテスト、renderはrenderだけでテスト。
#ただそれだとmakikiのレイヤはhttp側に寄りすぎてるかなあ。レンダリングのレイヤを一つ噛ませて、requestオブジェクトももうちょい抽象化すれば、ロジック側だけでテストできる体制になりそうな感じもする。
#makikiは内部が不透明になるのが嫌であまりリッチにしない方針なんだけど、一方でひとつファイル放り込んどけばそこそこ定形パターンはカバーできるってのも目指したいんだよなあ。
#なるほど。Node.js だと、そのままでも十分ウェブサーバとして機能するんですが、その上に Express という計量のフレームワークをのせて、さらにその上にミドルウェアをいろいろ重ねるような使い方をしています。 http://www.senchalabs.org/connect/ #ぼくはあんまりいろいろ重ねるのは好きじゃないので、割と低レベルな API をそのままつかってますが。
#あ、計量→軽量。
#敢えて汎用性を狙わずに、(1)低層のrequestオブジェクト+respond/*、(2)get/postパラメータから引数へのブリッジ、(3)sxmlベースの
#軽量テンプレート、くらいならそれほど複雑化しないかも。(1)は現状どおりで、細かいことがやりたかったらここまで降りる。(2)は、get/postで渡ってきたパラメータをあたかも引数で渡されたかのように変換してくれるブリッジ。(3)は Tree, [Params] -> Treeの単純な変換器。
#これだと、ロジック部分は引数を取ってテンプレートに渡す可変部分を返す、って具合にhttpから分離できる.