kintone開発覚え書き

この覚書は下記の開発サイクルを前提に考えられています。
想定している読者は kintone のカスタマイズはひとしきり覚えたものの、どのように開発サイクルを回せば良いか分からなかった数カ月前の自分です。

前提とする開発サイクル

1. dropbox など編集してすぐに動作を確認出来る方法で開発する
   • 参考の公式Tips: JavaScriptカスタマイズのデバッグをかんたんにするウラワザ

2. パッケージング

   • 開発したJavaScriptをアプリに添付する(外部から見えないようにするため)
   • アプリをテンプレート化する。
     • 参考の公式ヘルプ: アプリをテンプレート化する

3. デプロイ

   • 本番のデータをエクスポート
   • アプリを削除
     • この作業はルックアップなどの参照があるとかなり面倒です。スペースごと削除する方が良いのかもしれませんがまだ試せていません。2015年7月のアップデートでフォームの項目を変更するAPIも出来るらしいので一括で削除する処理を書くことが出来るようになるのかもしれません。
   • 2.でパッケージングしたテンプレートからアプリを作成
   • データをインポート

4. 追加の開発がある都度1.へ戻る。

各種tips

ルックアップでレコード番号を使わず、重複しない項目を設ける

レコード番号はインポート、エクスポートの際も自動採番されて変更することはできませんが、ルックアップの際に取得した項目はそのまま保持されるため関連が崩れます。
なのでレコード番号ではなく重複のない項目を使うべきだと思います。
どうしても重複のない項目が無い場合は下記の方法で解決出来るかもしれません。

• 複数の項目を繋ぐ項目を作成する。(例えば、会社名_部署名 と結合する項目を設けると重複が無くせるかもしれません。RDBのマルチカラムインデックスのような使い方です。)
• データ作成の際 UUID を生成する

アプリIDをハードコーディングせず、ルックアップや関連レコード一覧から取得する

冒頭に挙げた開発サイクルの通り、最終的なパッケージングはアプリテンプレートなのでアプリIDは変動します。
ここで言う"ハードコーディングしない"とは、プログラム上で定数にするという意味ではありません。

kintone の JavaScript API には下記のようにルックアップ、関連レコード一覧から参照先アプリIDを取得するメソッドがあります。

• kintone.app.getRelatedRecordsTargetAppId
• kintone.app.getLookupTargetAppId

REST APIであればフォーム設計情報取得で得られる relatedApp です。

アプリIDは絶対にコード上に含めず、上記の方法を使用することによってアプリIDが変動しても問題無くなります。
(アプリテンプレートから作成されたルックアップ、関連レコード一覧は関連が保たれています。)

ただし、必ずしもルックアップや関連レコード一覧がフォーム上にあるとは限りません。この解決策を私は知らないので、システム用とする編集不可のグループを作成しここに何の意味も無いアプリIDを取得するためのルックアップか関連レコード一覧を配置します。
あまり気持ちの良い方法ではないですが、デプロイ後に忘れずに参照先を変更する自信がないのでこうします。

テーブルを使わず、関連レコード一覧を使用する

複数の項目をアプリを増やすことなく手軽にできるテーブルですが、JavaScriptから扱いづらかったり、CSVでのインポートで反映できなかったり、再利用に向かない印象があります。
冒頭に挙げた開発サイクルで開発を行いたい関係上CSVでインポート出来ないのは困りますので、テーブルではなく関連レコード一覧を使用します。