無理矢理Railsのajax_scaffold型にするとこうなる
2006年08月15日(火) 22:16
Ajaxじゃない版に引き続き、せっかくなのでAjax版も作ろうとしてみました。
結論から言うと、失敗しました。
いや、そりゃやろうと思えばできるわけですが、なんというか
気分転換に国際化を施しました。
gettextが無くて、英語のままになりました。。。
せっかくなのでOSから再インストールします。ので、バリデーションエラーがでると何も無かったかのように振る舞う状態でとりあえず「完」。正常系は動きます。もし動かしてみたいという奇特な人がいたら、settings.pyの下の方を修正して走らせてみてください(エラーハンドリングにチャレンジしてみても楽しいかも)。
結論から言うと、失敗しました。
いや、そりゃやろうと思えばできるわけですが、なんというか
バリデーションエラーをインターナルサーバエラー扱いにするのが嫌
なので。RailsのAjax ScaffoldでDjangoになじまなかったところ
- responseヘッダに対象のオブジェクトのIDを忍ばせるところ。
気持ちはわからんでも無いのですが、genericビューをラップしなければならなくて面倒でした。
ajax_address/address/views.pyのdetailとdeleteというファンクションが本来であればいらないファンクションです。
なので、本来ビュー(他で言うコントローラ)に書かなければいけないのはpurgeというデータを初期化する部分だけです。 - バリデーション等、RailsのManipulatorに引っかかったものをhttpのレスポンスコード500で返すところ。
普段の非Ajaxアプリで、バリデーションエラーはレスポンスコード200ですよね？私がおかしい？
Prototype.jsとかのエラーハンドラが、レスポンスコード500系を扱うからなんでしょうね。
innerHTMLに結果をそのまま書き込むタイプだと、このあたりはひじょうにつらい。
Djangoのgenericビューのリターンは既にテンプレートレンダリング済みなはずだから、ラップしてっていうのが簡単にできるのかを考えるのも嫌で挫折。
本当になえたところ
macbookを買ったので、試しにXCodeを入れずにDjango環境を作成しました。気分転換に国際化を施しました。
gettextが無くて、英語のままになりました。。。
せっかくなのでOSから再インストールします。ので、バリデーションエラーがでると何も無かったかのように振る舞う状態でとりあえず「完」。正常系は動きます。もし動かしてみたいという奇特な人がいたら、settings.pyの下の方を修正して走らせてみてください(エラーハンドリングにチャレンジしてみても楽しいかも)。
