続いて更新、削除です。更新ですが、セルを編集した場合にステータスを更新に変更します。先の記事でも書きましたが、何もしていないデータにはサーバ側でも何もしないようにという意図です。諦めている点もあります。編集して「更新」ステータスにした後、もともと画面に表示していた値に再度戻したとしても「更新」状態のままです。初期状態2行目を編集して「値を変更した」場合は下記のようになります。この状態で反映を押下すると、サーバ側では2行目だけ処理して、1、3行目には何もしません。考慮すべき点は、サーバ側のことを考えると当然ですが、「追加」はUpdateにしません。サーバ側で読み取る前提ではない項目は判定から除外することです。ステータスそのものや、削除選択用のチェックボックスの値は判定から除外しています。」は言うまでもなくHandsontableのafterChange時に実行されるファンクションのインターフェイスがこれであるから、というお約束事です。ステータスや選択は対象外。削除するときは、DBから読み込んだ行については「削除」の印をつけてサーバ側に送信します。ないと、クライアント側からデータでの洗い替えになってしまいます。検索条件で一部を抽出して更新するときには、このような洗い替え方式は破綻するので、削除フラグを立てて送信する方式になるよう考えました。削除ボタン押下後ここでもう一つ考慮したことがあります。行追加した行の削除と、DBから読み取った行の削除では都合が違うという点です。後者は先に説明したように削除できるようステータスを更新して送信します。前者は、サーバ側に送ってもごみになるだけなので物理的に削除します。今回は、削除できる条件として「工数確定回数」が0の時だけというものを設定しています。そのような削除を許可する仕組みもある程度簡単につけられるように考えてみました。}注意点としては、物理削除することがあるので、行は後ろから削除しています。」この辺りから「削除の取り消し」を実装しています。再度削除して取り消し以上で、一括の登録、更新、削除をするための仕組みづくりができました。これから先は、クライアント側で編集したデータをサーバに送信する仕組みを書いていきます。Railsが前提なので、link_toのヘルパーも出てきます。上記のようなステータス制御が入る関係上、下記のような定義がhandsontableに必須です。これらを書くため、列幅で「見えないように」しています。気にする場合には、classnameも設定できるので、display:noneなクラスを当ててしまってもいいかもしれません。