はじめに
前置き
- 本記事は Qiita Advent Calendar 2023 の FileMaker Advent Calendar 2023 22 日目記事です。
- また、Claris FileMaker Pro で置換リスト変数を用いて複数フィールド内容のメンテナンス（+ちょっと ChatGPT を使う） という記事の続編となります。
対象読者
- Claris FileMaker ユーザ
- 複数のフィールドにおいて、複数の文字列を置換するようなメンテナンスが必要になる方
- 愚直に長いスクリプトステップを書きたくない方
- 「汎用的」とは？ など考えたい方
FileMaker とは？
モダンで幅広い業務に対応できる拡張性の高いカスタム App を作成
することが可能なもの、とのことです。
FileMaker 動作環境
- FileMaker Pro 20.x.x
- 19 以前でも動作するはずです
自己紹介
- 株式会社きみよりで代表をしています 野口啓之 / Hiroyuki Noguchi / Hi-Noguchi です
- IT を中心とした DX コンサル／顧問などやっております
- FileMaker については、内製化支援・トレーニングや 1on1 でのペアプロなど対応しています
前編記事でやったこと
前編記事のおさらいとして、以下のことを実現しました。
- 複数のフィールドに対して、それぞれの内容に不正な値がある場合、置換処理をおこなう
この際に、愚直に処理を書いていくと、長々としたスクリプトとなってしまいます。
よって、以下のような工夫を凝らして作成しました。
- 置換リスト変数を用意し、リスト行数分だけループ処理をおこなう
- モジュール処理用のスクリプトを切り分けて、汎用的に呼び出せるようにする
本記事でやること
本記事では、上記よりもさらに一歩踏み込んで汎用的なつくりにすることを目指します。
前編記事での具体的な箇所はこちら です。
処理全体をコピーします！
ジャネーヨ！ って話ですよね。はい、ごもっともでございます。
本記事は、その仮想ツッコミを受けてのリファクタリングが主な目的となります。
汎用的にするべき箇所を特定
ではまず、全体を眺めて、どこを汎用化できそうか考えます。
逆に言うと、どこが汎用化できないか、つまり、固有の箇所なのか、ということを特定しましょう。
まず 18 行目で フィールドへ移動 がありますが、ここは固有の箇所になりそうですね。
ここに移動することによって $target_table_name $target_field_name の値を取得しています。
あとは 40 行目の フィールド設定 や 42 行目の フィールド内容の全置換 でしょうか。
フィールド設定 は フィールドを名前で設定 で動的に指定できそうです。
また フィールド内容の全置換 は ターゲットフィールドの指定 をおこなわずに、その手前で該当フィールドに移動しておけば処理実行できますね。
手前で フィールドへ移動 すること前提なら、フィールドを名前で設定 も使わずにやれそうです。
……それならそもそも 27 行目で フィールドを名前で設定 するためにモジュール用スクリプト作って指定しているけれど、そんなことする必要ないじゃん！ フィールドへ移動 で ターゲットフィールドの指定 をおこなわなければいいじゃん！ というツッコミが入りそうです。
まあそうなんですよ、ぶっちゃけ。
前回はこういうやり方がありますぜーというご紹介でしたもので。
あとは、「フィールドにカーソルが入っていることが前提」みたいな作りがやや危ないというのはあります。
ただ、今回はそのあたりのリスクを背負って、綱渡りにギリギリな作りをあえてしてみる、という方針でリファクタリングしていくことにしましょう。
全体として見ると フィールドへ移動 以外は全部共通化できてしまいそうですね。
ではその方向性でやってみましょう。
リファクタリング_1
まず、この範囲を切り出します。
モジュール という名前を使うには不適切なほどの大きな処理ですね。
まあ、今回は気にしないでやっちまいましょう。
- モジュール_メンテナンス実処理 という名前のスクリプトを作成して、切り分けます。
まず超絶雑にやるとこんな感じです。
あまりに雑すぎるので、さすがに冒頭でのエラー処理を少し入れておきましょう。
このようにして、呼び出される経路を特定させるのと、フィールドが取得できていない場合のエラー処理を入れておきます。
呼び出し元でも引数を渡すようにしてあげましょう。
あとは以下の ターゲットフィールドの指定 を外してあげればヨシです。
それから最後に、メンテナンスのリストも実処理の方に移してしまいましょう。
出来上がり？
出来上がりです！ 短くなりました！
今後、対象フィールドが増えた場合には、四行だけ追加すれば大丈夫です。
……本当でしょうか。
メンテナンス スクリプト
- モジュール_メンテナンス実処理 スクリプト
上の方のキャプチャ画像では、上記キャプチャ画像 38 行目の 新規レコード/検索条件 が抜けているのですが、ここ重要です！
動作確認_1
以下のようなレコードがあったとします。
スクリプト実行！
ちゃんと二つのフィールドにおいて引っかかってくれました。
ただ、これで実行しても変換されません！
どうしてでしょうか？
……それは 検索実行 によってカーソルがフィールドから外れてしまうからなのです！
ここ。それはそう。
リファクタリング_2
そもそも、現状だと 検索モードに切り替え してから、検索実行をせずに スクリプト実行 で別スクリプトに移ってしまって、その中で検索実行をしているらしいぞ……という感じで推測しなければならず、コンテクスト依存度がとても高くて可読性が悪いなーとは思います。
なので、別解として、
- ここの選択部分を一つ目のモジュールとして切り出してスクリプト実行させる。
-
検索実行と$target_count変数の格納までは、呼び出し元のスクリプトでおこなわせる。 - そこから先の以下の箇所については、二つ目のモジュールとして切り出してスクリプト実行させる。
というようにする方が、全体としての可読性は上がると思いますし、これでちゃんと動くようになります。
モジュール という名付けにも適したものになりますし。
仮に先ほどのコードで動いていたとしても、短さだけを追求した設計というのは、往々にして作った本人（当時）以外の人には読みにくくなりがちです。
作った本人（未来）ですら読みにくくなります。
多少は長くなったり冗長な記述になったりしても、可読性を重視したつくりにする方をオススメしたいところです。
モジュールを二つに分割するとして、都道府県のリスト変数をどうするのか、という問題がありますね。
これについては JSON にして引数で持ち回すというやり方が一つあります。
ただ今回、そこまでの仕様改修を大掛かりにするのが面倒なので、手っ取り早くグローバル変数に押し込むようにしておきます。
あわせて各所の指定もローカル変数からグローバル変数に変えておきます。
計算式内も忘れずに。
テーブル名やフィールド名も引数で受け渡しするようにします。
モジュールは - モジュール_メンテナンス検索設定 - モジュール_メンテナンス置換処理 という名前で分けました。
出来上がり！
さて、これで今度こそ出来上がりです。
ちょっと呼び出し元の処理が長くなりましたね。
まあこのくらいはいたしかたなし。
メンテナンス スクリプト
- モジュール_メンテナンス検索設定 スクリプト
- モジュール_メンテナンス置換処理 スクリプト
動作確認
一応、動作確認だけしておきましょうか。
またまた以下のようなレコードがあったとします。
スクリプト実行！
ちゃんと二つのフィールドにおいて引っかかってくれました。
そして置換処理を実行したところ、二回目のメンテナンス実行時には引っかからないようになりました。
正常に処理完了しています。
お疲れ様でした！🎉
後書き
雑感
- この題材を通じて、「汎用的」とは何か？ 可読性を向上させるとはどういうことか？ など、少し体験していただけたかなと思います。
- コードを書いていると、あるいは読んでいると、本当にさまざまな実装方法があるものだと感じられるものですよね。短さと読みやすさというのは、トレードオフの関係になりがちなところがありますが、この記事なんかが考えるきっかけになったら嬉しいです！😀
PR
- FileMaker についてお困りのことがありましたら気軽にお声がけください🙌
-
FileMake Casualという Discord サーバも主催していますので、お気兼ねなくご参加ください！- https://discord.com/invite/PWWcYK8 ( 招待リンク )