ようやくサーバサイドとクライアントサイドの実装方法と
穴あけを完了して、共通実装部分の汎化も完了。
さてフォーム。を。
以前の実装をそのまま行くと
フィールドセットでまとめてくってことになるんだろうけど、
まずは
ひとつづつのコントロールはこうだった。
{ xtype : 'SystemCommonFormUserComboBox',
name:todo_dataMapping[18].name,
fieldLabel: todo_dataMapping[18].header,
hiddenName: todo_dataMapping[18].name,
width:80,
allowBlank: false }
これはもう固めてしまう。
では後はレイアウトとフォームパネルの仕様を決めてしまおう。
2010年5月31日月曜日
ExtJs－８５ Gridのサーバレスポンスを決めてみる。３
先日の８２，８３の結果を反映して
結局、
エラー時は、
{ 'total':'0',
'success': false ,
'data':[],
'resultMessage' : 'エラーメッセージ',
'resultOption' : ''
}
とかにしたんだけど、
この情報は、exceptionイベントハンドラの第五引数のrawの中に入ってくるみたい。
そのときのズ。
これは前のエントリにあったonWrite内のreader.readResponse
内のResponseオブジェクトがそういう風に作られているからそうみたいです。
dataオブジェクトにはgetRootで取得したroot情報を。
で、rawには引数で渡されたオブジェクトを渡してるので。
そんな具合。
res.raw.resultMessageとかでサーバエラー取得できる。
よしよし。解決。
結局、
エラー時は、
{ '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');
}
};
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－８３ 今日は勉強会
先月に続き、今月も参加できました。奇跡的だな。
「すごい」「かっこいい」と月並みな感想しかできず。
はじめてONGMAPと出会ったときのわくわくっていうか
そんな気分を感じられました。
これ、先日SpreadOfficeを見せていただいたときもこんな
感想だった。
はじめてONGMAPを見たとき、Webなのか？これ。って
そこから鳥肌たってJavaScriptというかWebAPに詳しくないのに
ExｔJs触り始めて。
ようやく慣れてきたころだったからそんな刺激がほしかったのかも
知れません。
GridをまるでExcelみたいに。っていう拡張、かっこよすぎでした。
クリップボードへの中継についても聞けてよかったです。
SpreadOfficeについても公開してくださるし。
レイアウトでのレスポンスの違いがうまれるなど、 Omegaについての説明など
なんだか刺激と勉強と。
いつも新しい発見をいただけるのですが、今回はまた新しい刺激をいただきました。
勉強になったなぁ。と。
そういや、@naotoriさんがONGMAPの作者って
気がついたのしばらくたってからだったんだよなぁ。
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を返す場合に発火します。 アクションの成功、または失敗は
misleadかな。あたた。
フォームのほうはExtJs本洋書に載ってるのとExtJS入門を参考にしてもう一度
今の実装を見直せばOKだし。
先がみえてきたかもｗｗ。
つぶやいたりなんだりしたたらいつの間にか気づくと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。
参照させていただいてます。
リンクはらせていただきました。
ありがとうございます。。
さて、サーバレスポンスを決めようかと。
まーた、あっち行ったりこっち行ったりの実装で
こまったものですが、
もう少しで自動生成部分の切り出しが
できそうになって来ました。
パラメータ部分は落ち着いてフィールド構成と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日木曜日
2010年5月8日土曜日
ExtJs－８０ 継承の書き方を決めてみる。（とうとう仕事でコードを書かなくなった）
とうとう仕事でコードを書くことがなくなりました（笑）
めでたく（？）趣味プログラマになりました。
まぁ、趣味で自由にやってたほうが気が楽なので割り切りますが、寂しい限りです。
さて、ExtJsにであってJavaScriptを触り始めましたが、
ほんのすこし慣れてきたような気がします。
でもいつかExtJsを仕事でつかうんだ！という野望は捨てず
遊び続けよう！！
さて、
先日お絵かきしたものを実装するにあたりJavascriptってやわらかくて
実装方法がいろんな書き方があってあっちいったりこっち行ったりして
自分ルールが決まってませんでした。あるソースではthis拡張で継承したり
あるソースではprototypeの継承なんだけど書き方がちがったりと。
いまだに慣れません。コード書いてる量も少ないし。。
誰に聞きくでもなく（先日夜中@kotsutsumiさんにクロージャについて聴いちゃいましたが）、
会社の人間にも聞ける人いないしなぁ。
ということで
これまたエイヤと決めました。（initは便宜上ってことを書いておかないとあとで忘れる）
■抽象クラスはこーしよう
Ext.ns('test');
//抽象クラスのためコンストラクタ実装なし。としてみる。普通にインスタンス化できちゃうけどなぁ。
test.AbstractClass = function () {};
//基底クラスだから継承なし。でここでは実装せず、ほかにあわせて、わざと空実装にしてしまおう。
test.AbstractClass.prototype = {};
//protptype.xxxをいちいちやるのは面倒な実装。これ好き。
(function () {
var me = this;
//メンバ
me.abstractMember = {};
//private
me.init = function (config) {
var me = this;
me.abstractMember = config;
};
//抽象クラスのメソッド（オーバーライドがされることの確認用）
me.testalert = function () {
var me = this;
alert('AbstractClass');//こいつが呼び出されるとこまる
};
}).apply(test.AbstractClass.prototype);
■具象クラスはこーしよう
Ext.ns('test');
//具象クラス コンストラクタ
test.ConcreteClass = function () {
var me = this;
//superclass init ヨビダシ。
me.init.apply(me, arguments);
};
//prototype継承
test.ConcreteClass.prototype = new test.AbstractClass();
//protptype.xxxをいちいちやるのは面倒な実装。これ好き。
(function () {
var me = this;
//オーバーライドできてるかな？
me.testalert = function () {
var me = this;
//継承したプロパティをちゃんと参照できてるか？
alert(me.abstractMember);
};
}).apply(test.ConcreteClass.prototype);
■確認
Ext.onReady(function() {
//testConcreteを生成（内部でSuperSuperClassのinitを呼び出し、SuperClassのプロパティに値を設定）
var testConcrete = new test.ConcreteClass('ConcreteClass');
testConcrete.testalert();
});
方針もかたまり、おおむね実装も完了しそう。。、もうちょいなかんじなんだよなぁ。
実装にあたって勉強させてもらいました。
が、読むのがやっとです。
ありがとうございました。
いやぁ、おもしろいなぁ、むずかしいなぁ。と。
■JavaScript OOP におけるクラス定義方法
http://d.hatena.ne.jp/amachang/20060516/1147778600
http://d.hatena.ne.jp/amachang/20080208/1202448348
■猿でもわかるクロージャ超入門 まとめ - DQNEO起業日記
http://dqn.sakusakutto.jp/2009/01/javascript_5.html
■JavaScript継承パターンまとめ
http://d.hatena.ne.jp/shogo4405/20070121/1169394889
■プロトタイプ（prototype）による JavaScriptのオブジェクト指向
http://codezine.jp/article/detail/222?p=1
■Javascript/ 継承/protected的メンバ作成
http://yakinikunotare.boo.jp/orebase/index.php?Javascript%2F%B7%D1%BE%B5%2Fprotected%C5%AA%A5%E1%A5%F3%A5%D0%BA%EE%C0%AE
■JavaScriptの再利用とapply
http://mumrik2.spaces.live.com/blog/cns!51ED6D671E97A131!223.entry
■JavaScript で継承やるときにprototype書きまくるのめんどい人は
http://d.hatena.ne.jp/iskwn/20091215/1260828978
めでたく（？）趣味プログラマになりました。
まぁ、趣味で自由にやってたほうが気が楽なので割り切りますが、寂しい限りです。
さて、ExtJsにであってJavaScriptを触り始めましたが、
ほんのすこし慣れてきたような気がします。
でもいつかExtJsを仕事でつかうんだ！という野望は捨てず
遊び続けよう！！
さて、
先日お絵かきしたものを実装するにあたりJavascriptってやわらかくて
実装方法がいろんな書き方があってあっちいったりこっち行ったりして
自分ルールが決まってませんでした。あるソースではthis拡張で継承したり
あるソースではprototypeの継承なんだけど書き方がちがったりと。
いまだに慣れません。コード書いてる量も少ないし。。
誰に聞きくでもなく（先日夜中@kotsutsumiさんにクロージャについて聴いちゃいましたが）、
会社の人間にも聞ける人いないしなぁ。
ということで
これまたエイヤと決めました。（initは便宜上ってことを書いておかないとあとで忘れる）
■抽象クラスはこーしよう
Ext.ns('test');
//抽象クラスのためコンストラクタ実装なし。としてみる。普通にインスタンス化できちゃうけどなぁ。
test.AbstractClass = function () {};
//基底クラスだから継承なし。でここでは実装せず、ほかにあわせて、わざと空実装にしてしまおう。
test.AbstractClass.prototype = {};
//protptype.xxxをいちいちやるのは面倒な実装。これ好き。
(function () {
var me = this;
//メンバ
me.abstractMember = {};
//private
me.init = function (config) {
var me = this;
me.abstractMember = config;
};
//抽象クラスのメソッド（オーバーライドがされることの確認用）
me.testalert = function () {
var me = this;
alert('AbstractClass');//こいつが呼び出されるとこまる
};
}).apply(test.AbstractClass.prototype);
■具象クラスはこーしよう
Ext.ns('test');
//具象クラス コンストラクタ
test.ConcreteClass = function () {
var me = this;
//superclass init ヨビダシ。
me.init.apply(me, arguments);
};
//prototype継承
test.ConcreteClass.prototype = new test.AbstractClass();
//protptype.xxxをいちいちやるのは面倒な実装。これ好き。
(function () {
var me = this;
//オーバーライドできてるかな？
me.testalert = function () {
var me = this;
//継承したプロパティをちゃんと参照できてるか？
alert(me.abstractMember);
};
}).apply(test.ConcreteClass.prototype);
■確認
Ext.onReady(function() {
//testConcreteを生成（内部でSuperSuperClassのinitを呼び出し、SuperClassのプロパティに値を設定）
var testConcrete = new test.ConcreteClass('ConcreteClass');
testConcrete.testalert();
});
方針もかたまり、おおむね実装も完了しそう。。、もうちょいなかんじなんだよなぁ。
実装にあたって勉強させてもらいました。
が、読むのがやっとです。
ありがとうございました。
いやぁ、おもしろいなぁ、むずかしいなぁ。と。
■JavaScript OOP におけるクラス定義方法
http://d.hatena.ne.jp/amachang/20060516/1147778600
http://d.hatena.ne.jp/amachang/20080208/1202448348
■猿でもわかるクロージャ超入門 まとめ - DQNEO起業日記
http://dqn.sakusakutto.jp/2009/01/javascript_5.html
■JavaScript継承パターンまとめ
http://d.hatena.ne.jp/shogo4405/20070121/1169394889
■プロトタイプ（prototype）による JavaScriptのオブジェクト指向
http://codezine.jp/article/detail/222?p=1
■Javascript/ 継承/protected的メンバ作成
http://yakinikunotare.boo.jp/orebase/index.php?Javascript%2F%B7%D1%BE%B5%2Fprotected%C5%AA%A5%E1%A5%F3%A5%D0%BA%EE%C0%AE
■JavaScriptの再利用とapply
http://mumrik2.spaces.live.com/blog/cns!51ED6D671E97A131!223.entry
■JavaScript で継承やるときにprototype書きまくるのめんどい人は
http://d.hatena.ne.jp/iskwn/20091215/1260828978
登録:
投稿 (Atom)