Sencha Ext JS 4 – Ext Directの通信エラーハンドリング | Sencha Advent Calendar 2013 – 9日目

sencha-logo この記事は、 Sencha Advent Calendar 2013 の9日目の記事です。

さて、いままでSencha Touchについて書いてきましたが、1回くらいはSencha Ext JSのネタを入れたいなぁと思います。

今日は、Ext Directにおける通信エラーハンドリングについてです。

Ext Directと題していますが、ここでお話するのは、Ext.form.Panelクラス(フォームパネル)のsubmit時処理についてです。


通信エラーハンドラ、failure

人の書いたコードを見ていると、Ext.form.Panel.submitを呼び出した時のコードが、次のようになっていることがあります。

「おい、failureどこ行った?」

と思うと、次のようなコードもあります。

「・・・。」

そんなに、failure嫌いですかね(笑)

まぁ、正直「書くことがない」っていう回答が多いようですが、本当にそうでしょうか。

APIドキュメンテーションをみてみましょう。

http://docs.sencha.com/extjs/4.2.2/#!/api/Ext.form.Basic

もう、僕が何かを語る必要もない気がしますが…

failureに設定した、コールバック関数の引数には、第二引数にactionオブジェクトが渡されます。 そのプロパティであるfailureTypeを判定しましょう。

  • Ext.form.action.Action.CLIENT_INVALID
  • Ext.form.action.Action.CONNECT_FAILURE
  • Ext.form.action.Action.SERVER_INVALID

http://docs.sencha.com/extjs/4.2.2/#!/api/Ext.form.action.Action-static-property-CLIENT_INVALID

が返された場合、それぞれ何が原因でエラーが起きているのかを特定することができます。

以上ですwww

まとめ

やっぱり、「failure後で書こう」と思って、そのままリリースしたり、特に書くことがないと放置したりしているソースをみていると、最低限上記のような対応を記述しておいた方がいいかもしれません。

プロジェクトでやるなら、Formクラスを継承した抽象クラスを作成して、エラー処理を実装させ、共通化します。

failureFnが抽象クラスで定義されているメソッドです。 任意の引数を与えたい場合は、上記のように、Ext.Function.passを利用しましょう。

これで、今日から、放置気味なfailureとも、お別れです。

是非、活用してください。

Sencha Ext JS 4 – Ext Directの通信エラーハンドリング | Sencha Advent Calendar 2013 – 9日目

2 thoughts on “Sencha Ext JS 4 – Ext Directの通信エラーハンドリング | Sencha Advent Calendar 2013 – 9日目

Comments are closed.