為せば成るとはいうものの、またですか？またですね。

2010年5月31日月曜日

ExtJs－８６　グリッドは本当に一旦終了。でフォームの開始

ようやくサーバサイドとクライアントサイドの実装方法と
穴あけを完了して、共通実装部分の汎化も完了。

さてフォーム。を。
以前の実装をそのまま行くと
フィールドセットでまとめてくってことになるんだろうけど、
まずは
ひとつづつのコントロールはこうだった。

{ xtype : 'SystemCommonFormUserComboBox',
                              name:todo_dataMapping[18].name,
                              fieldLabel: todo_dataMapping[18].header,
                              hiddenName: todo_dataMapping[18].name,
                              width:80,
allowBlank: false }

これはもう固めてしまう。
では後はレイアウトとフォームパネルの仕様を決めてしまおう。

ExtJs－８５　Gridのサーバレスポンスを決めてみる。３

先日の８２，８３の結果を反映して
結局、

エラー時は、
{ 'total':'0',
'success': false ,
'data':[],
'resultMessage' : 'エラーメッセージ',
'resultOption' : ''
}

とかにしたんだけど、
この情報は、exceptionイベントハンドラの第五引数のrawの中に入ってくるみたい。

そのときのズ。

これは前のエントリにあったonWrite内のreader.readResponse
内のResponseオブジェクトがそういう風に作られているからそうみたいです。

dataオブジェクトにはgetRootで取得したroot情報を。
で、rawには引数で渡されたオブジェクトを渡してるので。
そんな具合。

res.raw.resultMessageとかでサーバエラー取得できる。
よしよし。解決。

2010年5月27日木曜日

ExtJs－８４　writeイベントとsaveイベントの問題とexceptionイベント

なぜかわからないけど、
saveイベントにwrite用のハンドラが設定してあって。。
いわずもがな、write用に実装してあるから
期待した結果は得られないわけです。

直しました。過去のエントリでsaveイベントが発火されてwriteが呼ばれる云々
ってのはこれが原因でした。ごめんなさい。

で、今の基礎実装でサポートするのは
write
load
exception
と絞って実装することにした。

exceptionイベントハンドラの実装をモデルに追加して
今回の騒動もひとまず終了。

exceptionの
type:　remoteとresponseの違いは
httpProxyのonWrite
reader.readResponseを実行してるブロック内で
例外が発生した場合はresponse
そうじゃなくてsuccessがfalseで設定されてきた場合はremoteと。
そんな具合っぽいです。

>（ほかのProxyクラスもたぶん同様になってるとおもう。ScriptTagProxyはそうだった。
>ブロックといってもres = reader.readResponse(action, response);の一行ですが、
>内部ではレスポンスの有無、rootの有無！！←（これこれ）。
>レスポンスオブジェクト生成、successプロパティ有無のチェックなどをやってます。）
>＃rootの有無チェック・・・これらすべてちゃんとexception投げてくれてるではないか！
>＃過去のwriterでどはまりした件。。。だからちゃんと実装しないとどはまりする。

だから雰囲気としてはこんなかんじになるのかな。
exceptioncallback = function(proxy, type, action, options, res, arg) {
    var me = this;
    if (type === 'remote') {
        alert('serverサイドでの不備');
    } else if (type === 'response') {
        alert('response内容解析中の例外発生');
    }
    //画面の再描画
    if (me.view.hasListener('crudreflesh')) {
        me.view.fireEvent('crudreflesh');
    }
};

ExtJs－８３　今日は勉強会

先月に続き、今月も参加できました。奇跡的だな。

事例で学ぶExt JSとクラウドのマッシュアップ（マッシュマトリックス冨田様）
アプリ紹介 - SpreadOfficeの紹介（小堤）

でした。
「すごい」「かっこいい」と月並みな感想しかできず。
はじめてONGMAPと出会ったときのわくわくっていうか
そんな気分を感じられました。
これ、先日SpreadOfficeを見せていただいたときもこんな
感想だった。

はじめてONGMAPを見たとき、Webなのか？これ。って
そこから鳥肌たってJavaScriptというかWebAPに詳しくないのに
ExｔJs触り始めて。
ようやく慣れてきたころだったからそんな刺激がほしかったのかも
知れません。

GridをまるでExcelみたいに。っていう拡張、かっこよすぎでした。
クリップボードへの中継についても聞けてよかったです。

SpreadOfficeについても公開してくださるし。
レイアウトでのレスポンスの違いがうまれるなど、 Omegaについての説明など
なんだか刺激と勉強と。

いつも新しい発見をいただけるのですが、今回はまた新しい刺激をいただきました。
勉強になったなぁ。と。

そういや、@naotoriさんがONGMAPの作者って
気がついたのしばらくたってからだったんだよなぁ。

ExtJsと出会ってずいぶん時間がたったくせに
ぜんぜん進んでないなぁ。
まぁ、半趣味だからそれくらいがいいのかな。と。

2010年5月26日水曜日

ExtJs－８２　Gridのサーバレスポンスを決めてみる。２

今日はPC立ち上げないって思ってたんですが、
つぶやいたりなんだりしたたらいつの間にか気づくとExtJsをちらちら。

昨日のエントリでエラーはどーすんの？って自問してたけど、
なんちゃない、
http://www.extjs.com/deploy/dev/examples/writer/writer.html

あるじゃんか。

しょぼしょぼしょぼ。
でもね、APIDocのほうにはそれとなくもしサーバーがExt.data.Api.actionsのCRUDアクションの後にHTTPステータスコード200を返す場合に発火します。アクションの成功、または失敗はresult['successProperty']で入手可能です。もしデータベース認証が失敗するならば、サーバーコードはsuccessPropertyをfalseとセットするでしょう。ってある。

misleadかな。あたた。
フォームのほうはExtJs本洋書に載ってるのとExtJS入門を参考にしてもう一度
今の実装を見直せばOKだし。

先がみえてきたかもｗｗ。

2010年5月25日火曜日

ExtJs－８１　Gridのサーバレスポンスを決めてみる。

ほんと一切、仕事でコードを書かなくなりました。

さて、サーバレスポンスを決めようかと。

まーた、あっち行ったりこっち行ったりの実装で
こまったものですが、
もう少しで自動生成部分の切り出しが
できそうになって来ました。

パラメータ部分は落ち着いてフィールド構成と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。

参照させていただいてます。
リンクはらせていただきました。
ありがとうございます。。

2010年5月20日木曜日

ねてしまう

今日は新しい職場でのキックオフ会。
おとといお客様が開いてくれた歓迎会で山手線トリックにかかり（というかねすごしただけ）

終電を逃してタクシ。
さて、今日は新しい職場でのキックオフ。

で、やはり山手線トリック。

ああ、いたた。で、近くまできてタクシ。
のまえに松屋で牛メシを食べる。そして眠い。明日五時おき。もう。。。
久しぶりのブログエントリがぐだぐだ。

かえって、さくっと寝るぞ。

登録: 投稿 (Atom)