フォームの入力はすべて、その型に基づいて有効性がチェックされます。たとえば、Number 型の列は入力として Hello を受け入れません。Valid_If による列の制御は、入力の有効性をチェックする際に、高度なデータ依存型ロジックが必要になる状況で使用する式です。
Valid_If 制御は、関連づけられた列に対するユーザー入力が有効かどうかを決定する条件式です。
以下は、一般的に使用されている Valid_If 制御の例です。
- 列の値が 1 つのシンプルな条件を満たすかどうか。たとえば、値を定数と比較したり（
[_THIS] > 5など）、値を別の列を比較したり（[_THIS] > [ColumnA]など）します。 - 特定の列の値がリストに含まれるかどうか。これには、次のいずれかの方法を使います。
- Valid_If のプルダウン で説明されているように、リストからプルダウン メニューを作成する。
- もしくは、値のプルダウン メニューを作成せずにフォーム入力を検証する。例:
AND(TRUE, IN([_THIS], LookupTable[ColumnC]))AND(TRUE, IN([_THIS], SELECT(LookupTable[ColumnC], ([ReportDate] > (TODAY() - 7))))
無効な入力があると、データが保存されなかったり、フォームの次のページに進めなかったりすることがあります。詳細ビューのフォームや Quick Edit 列で変更されたデータについては、表示されている入力にのみ Valid_If 制限が適用されます。理由は次のとおりです。
- 列を非表示にしたり、ビューから省略する方法はたくさんあるため（たとえば、スライスから除外する、列の順序から除外する、分岐フォームの異なるページで除外するなど）、ユーザーをブロックすることが意図もしくは想定されていたのかどうかが不明確なことがよくあります。
- 非表示列の有効性の検証が失敗したことでユーザーがブロックされた場合、一般的にはユーザーがそれを修正する方法はなく、また次のページに進めない理由もユーザーにとって明確ではありません。アプリ作成者がユーザーをそこでブロックすることを意図していなかった場合、ユーザーもその理由を理解できず、生産性の低下につながる可能性があります。
なお、Valid_If 条件は非表示の列の値も参照できるため、非表示の値によりフォームをブロックしたい場合は、式を表示列に追加してください。
アクションによる更新に関しては、Valid_If 条件は 2 つのケースで適用されます。
- 更新される列が無効になった場合、更新はブロックされます。
- 更新によって別の列が無効になった場合、更新はブロックされます。
つまり、アクション自体に関係のない既存の無効な値によってアクションがブロックされることはありません。
Valid_If と依存プルダウン
依存プルダウン メニューは入力を取り込むアプリでよく使用される設計パターンです。たとえば、Lead Tracking テンプレートのようなアプリで、Lead Region（America, Asia, Europe）について質問してから、その後にその地域内の Country を質問するとします。これを行うには比較的複雑なロジックが必要になりますが、AppSheet ではこれをシンプルに行うことができます。依存プルダウン メニューは、別に用意されたルックアップ テーブルを使用して動作します。
サンプルでは、許可されている地域と国の組み合わせを示す 2 つの列（Region と Country）を含む別の Regions ルックアップ テーブルがあります。
Lead Region 列には、通常の Valid_If 制御、Regions[Region] が指定されています。そのため、新しいエントリを入力しようとすると、この列の入力として 3 つの選択肢、America、Asia、Europe が表示されます。
同様に、Country 列には似たような Valid_If 制御、Regions[Country] が指定されています。この列は Lead Region 列の後に来るもので、また、どちらの列も同じルックアップ テーブル Regions の列を指定しているため、AppSheet がその意図を理解して、依存プルダウン メニューを適用します。
AppSheet は内部的に、Country 列で許可される一連の値を取得する式を作成します。この式には以下の内容が含まれているはずです。
Regionsテーブルを参照する。- 行をフィルタリングして、このテーブルの
Region列が、フォームで編集されている行のLead Region列の値と一致するようにする。 - このようにフィルタリングした行から
Country列を抽出する。 - 重複を除外し、これが許可される国のリストになる。
Lead Regionが変更されるたびにリストを再計算する。
式について知りたい方向けに説明すると、厳密には、基になる AppSheet の完全な式は以下のようになります: IN( [_THIS], SELECT(Regions[Country], [_THISROW].[Lead Region] = [Region]))
ほとんどのアプリ作成者にとって、このような複雑な式を指定しなければならなくなることはまずありませんが、Valid_If 制御としてこの式を実際に指定することは可能です。高度なユースケースのために知っておくと便利です。たとえば、等式の条件を使用するのではなく、不等式の条件やより複雑な式を使用して、表現力に優れた動的なプルダウン メニューを構築することもできます。
EnumList フィールドの「failed Valid_If condition」のトラブルシューティング
この問題は、EnumList フィールドが有効な値のリストを含む Valid_If 式を指定している場合に発生します。EnumList フィールドに 2 つ以上の値を含むレコードを保存しようとすると、Valid_If 条件が失敗します。また、CSV Import も失敗して次のメッセージが表示されます。
「Error: Row having key '<キー値>' in table '<テーブル名>' containing value '<EnumList フィールド値>' failed Valid_If condition」
たとえば、EnumList フィールドに以下のような Valid_If 式が指定されているとします。
LIST("A", "B", "C", "D")
システムはこの Valid_If 式を以下の同等な Valid_If 式に自動的に変換します。[_THIS] は現在のフィールドの値を指すことに注意してください。この場合は、EnumList フィールドです。
IN([_THIS], LIST("A", "B", "C", "D"))
サーバーの式システムは、IN 式を評価する際に、EnumList フィールドが値のリストを含む可能性があることを検出できません。そのため、EnumList の値を LIST の各値と比較する 1 つの値として誤って扱ってしまいます。たとえば、EnumList フィールドが「A、C」を含む場合、「A、C」を LIST 値「A」、「B」、「C」、「D」と順に比較します。EnumList 値「A、C」はこれらの値のいずれとも一致しないため、Valid_If 条件は失敗します。