ほんと一切、仕事でコードを書かなくなりました。
さて、サーバレスポンスを決めようかと。
まーた、あっち行ったりこっち行ったりの実装で
こまったものですが、
もう少しで自動生成部分の切り出しが
できそうになって来ました。
パラメータ部分は落ち着いてフィールド構成とxtypeだけ定義すれば
普通のEditorグリッドはできるようにはなったとして、
通信部分の取り決めを明記しておかないから久しぶりに見るとわからなくなる。。
Gridでのレスポンスはreadと同様のJSON構成で
IDをRequestとあわせるということに決めた。
■Grid時のまとめ
readerのmetaは
var meta = {
idProperty: 'id',
successProperty: 'success',
totalProperty: 'total',
root: 'data'
};
と。
必然的に
writerのmetaも
var meta = {
idProperty: 'id',
successProperty: 'success',
totalProperty: 'total',
root: 'data'
};
こうなる。
だから、
Update、Insert時のリクエスト時は
リクエストの['data']に格納されているJson(まるっと一行分のレコード情報)データが更新、追加対象となるため、
JsonをLinqオブジェクト(の配列:実装上の便宜上配列)に変換する。
(Newtonsoft.Json.Linq.JArray)
Delete時のリクエスト時は
リクエストの['rows']に格納されているJsonデータが削除対象idのカンマ区切りのため
splitかけてNewtonsoft.Json.Linqが解析できる形に一度整形しなおして
JsonをLinqオブジェクト(の配列:実装上の便宜上配列)に変換する。
(Newtonsoft.Json.Linq.JArray)
Select時はDataTableをJsonにこつこつと変換。文字コードも気をつけて、ね。
※でも、エラー情報の載せこみってどうすんだろかなぁ。
・エラー時はというと。。。
writeのハンドラ引数のresultっていうのはdataになるわけで、
dataオブジェクトのなかにエラーメッセージを入れてやることになるのかな?
よくわからなくなってしまったのが、
successにfalseを設定しておくとことごとくwriteイベントは呼ばれず、
最後にremoveFromBatchのなかのsaveイベントがfireされるということ。
その発火によってかwrite用にセットしたイベントハンドらが呼ばれる(?)んだけど、
そうするとwriteの期待した引数ではなく、saveイベント用の引数になる。
あとroot(今回のdata)のなかみは配列にしておかないとreadResponseで
root.lengthでみてdataを引っ張り出すのでオブジェクトにするにもちゃんと配列じゃ
ないとだめ。
っていうか、サーバサイドからのエラー情報ってどうすんだろ。
いかん、あと3時間半後に起床。。あーあ。
それとものすごい頻度とわかりやすい内容で名古屋ExtJsの方のサイトが更新されてます。
code:xと名古屋ExtJS。
参照させていただいてます。
リンクはらせていただきました。
ありがとうございます。。
0 件のコメント:
コメントを投稿