intra-mart準拠の関数でAjaxを実装するかjQueryを使うか

今日はイントラマートネタです。(intra-martとどっちがいいのか迷っています。

イントラマートはwebアプリなのですが、バックエンド側をJavaで書くのかJavaScriptで書くのかの2つあり、今回はJavaScript側での実装を想定しています。(スクリプト開発)

Ajax自体はjQueryで実装できますが、intra-martの場合はグローバル関数にimspAjaxSendimuiAjaxSendがあります。

これらの関数はjQuery準拠の挙動を示すのですが、サクッと実装するのであればグローバル関数を使用すると良いと思います。ただ、基本的にはjQueryの実装をしておいた方がバージョンアップ時に苦しまないかなぁという印象でした。

intra-mart準拠のものについて

intra-mart自体のweb上の資料が差分が見れないこともあり使用するか迷いましたが、実装が楽できるから下記の2つの理由の場合は利用していました。

1.ファンクションコンテナ側のaction処理を指定してpostしたい場合

2.post後の挙動が複雑ではない場合

になります。

actionで指定してpostしたい場合

intra-martはページロード時に、ファンクションコンテナ側のinit()が必ず実行されます。

そのため、Ajaxでpostを行う時にはinit()内に処理を用意しておくか、init()実行前に割り込んで処理を実行するaction処理を利用して実装を行っていきます。

jQueryの$.ajax()でもファンクションコンテナ側の処理は変わらないのですが、ルーティングテーブルにURLとaction属性を別途指定する必要があり、ケースバイケースになりそうです。

initに実装しても良いですが(実装例ではそうしてある)、できるだけロジックを分離しておきたいので。

なお、アクション処理実行後にinit()はロードされますが、httpResponseのimuiAjaxSend ( "#form", "post", "json", function(jqXHR){ //送信前の処理を書く(ロード画面を見せる等) }, function(jqXHR){ //送信完了時の処理を書く。ifで成功、失敗を書く感じ… });

サーバーサイドの実装は公式ページが参考になります。

(intra-mart Accel Platform UIデザインガイドラインajaxの実装例)

function init(request) {
    ...
    response.setContentType('application/json; charset=utf-8');
    ...
    var resultObject = SomeAPI.doSomething();
    if (resultObject.error) {
        // 処理が失敗した場合
        response.sendMessageBodyString(
            ImJson.toJSONString({
                error: resultObject.error,
                errorMessage: resultObject.message,
                detailMessages: ['管理者にお問い合わせください', '連絡先:admin@xxx.xxx.xxx']
            })
        );
    }

    // 処理が成功した場合
    response.sendMessageBodyString(
        ImJson.toJSONString({
            error: false,
            errorMessage: '',
            successMessage: '登録しました',
            parameter:{
                param1: 'value1',
                param2: 'value2',
                array1: ['array1', 'array2', 'array3']
            }
        })
    );
}

感想:工数によっては自前で実装した方がいいかなぁ

まとまってしまいましたが、フレームームワークなのでバージョンアップの問題が関わってきます。特にintra-martはビジネス基盤で長い期間の利用を想定するとバージョンアップで推奨ではなくなる可能性がある要素はできるだけ排除しておきたいというのがあります。(ドキュメント類を見ると結構非推奨が増えてる)

フレームームワークに乗っかると通知や管理は楽で誰が実装しても近い仕上がりになるので、品質を揃えたい場合はグローバル関数を利用するのも視野に入ってきます。…というフレームームワークを利用しているとあるあるな感じのまとまり方です。

シェアする

  • このエントリーをはてなブックマークに追加

フォローする