[AEM Forms]{class="badge positive" title="AEM Formsに適用)。"}
ルールエディターの機能強化とユースケース
これらは、 プレリリースチャネルから利用できるプレリリース機能です。 これらの機能強化は、Edge Delivery Services Formsにも適用できます。
ここでは、Adaptive Formsのルールエディターの最新の機能強化について説明します。 これらのアップデートは、カスタムコードを記述することなく、フォームの動作をより簡単に定義できるように設計されており、より動的でレスポンシブでパーソナライズされたフォーム体験を実現します。
次の表に、アダプティブ Formsのルールエディターに対する最近の機能強化と、各機能の簡単な説明と主な利点を示します。
での詳細な検証 – ターゲットエラーメッセージ
によるユーザーエクスペリエンスの向上 – 不完全なデータ
による進行の防止 – フォーム送信エラーの軽減
のダウンロードにカスタム開発は必要ありません – フォーム間で一貫したダウンロード体験
を有効にする – 重複ロジック
の必要性を減らす – 非表示のフィールドを作成する必要がなくなります
をサポート – ルールを実行するタイミングと方法をより詳細に制御
- インタラクティブ性を強化
の正確なルールアプリケーション – 動的セクション
のエラーを軽減 – 繰り返しコンテンツによるユーザーエクスペリエンスを向上
- アップロードシナリオの連鎖ルールが少ない
- ファイルと検証済み入力を一緒に必要とするフォームのオーサリングがより明確になります
に基づくパーソナライゼーションを有効にします – マーケティングまたはトラッキング固有のフロー
に役立ちます – 追加のスクリプトやカスタマイズは必要ありません
次に、これらの機能を利用して、ユーザーにパーソナライズされた体験を提供する方法を把握するために、具体的なユースケースを用いて各方法を詳しく説明します
関数リストのメソッドの検証
validate () メソッドを関数リストで使用して、パネル、フィールド、またはフォーム全体を検証できるようにする、拡張検証機能。 たとえば、マルチステップのローン申し込みフォームでは、利用者が次のステップに進む前に、さまざまなセクションを検証する必要があります。
シナリオ:金融機関は、ユーザーが次のような異なるセクションに記入する必要があるマルチステップのローン申し込みフォームを提供しています。
- 個人の詳細情報
- 雇用の詳細
- ローン詳細
- レビューして送信
ユーザーがあるステップから次のステップに移動する前に、フォームは現在のセクション内のフィールドのみを検証する必要があります。 例えば、「個人情報」の必須フィールドがすべて正しく入力されていない限り、ユーザーは「雇用詳細」に進むことができません。
ルールエディターでvalidate ()を使用した実装
各パネルの次へ ボタンは、validate () メソッドを使用してルールをトリガーします。 ルールは、現在のパネルのすべてのフィールドが有効かどうかをチェックします。 検証に合格すると、フォームは次のパネルに移動します。 そうでない場合は、エラーメッセージが表示され、ユーザーが入力を修正するように導きます。
次のスクリーンショットは、次へ ボタンに適用されたルールを示しています。
上記のルールでは、次 ボタンは、個人情報 セクションのフィールドが有効かどうかを確認します。 詳細が無効な場合、フォーカスは個人情報 パネルの名前 フィールドに移動します。
レコードのドキュメントをダウンロード
ルールエディターで DownloadDor () 標準提供(OOTB)関数を使用すると、フォームが記録文書を生成するように設定されている場合、ユーザーは記録文書をダウンロードできます。
シナリオ:官公庁が証明書の発行用にデジタル申請フォームを提供します。 フォームを送信した後、応募者は自分の記録のために完成したフォームのコピーを必要としたり、別の部門と共有したりすることがよくあります。 ユーザーエクスペリエンスを向上させるために、同局は、提出直後、または最終提出前の任意の段階で、記録文書(DoR)をダウンロードするオプションを応募者に提供したいと考えています。
ルールエディターでDownloadDor ()を使用した実装
ルールエディターを使用して、ダウンロード ボタンがフォームに追加されます。ボタンをクリックすると、DownloadDor ()関数をトリガーするようにルールが設定されます。
次のスクリーンショットは、ダウンロード ボタンに適用されたルールを示しています。
フォームがDoR生成用に設定されている場合、この関数はカスタム関数を必要とせずに、PDFを即座に生成してダウンロードします。
ルールでの動的変数のサポート
拡張ルールエディターでは、動的(一時的)変数の作成と使用がサポートされています。 これらの変数は、組み込みの 変数の値を設定 および 変数の値を取得 関数を使用して、フォームのライフサイクル全体を通じて設定および取得できます。
これらの変数:
- フォームデータで送信されません。
- 中間値または計算値を保持できます。
- 条件付きロジックやアクションで使用できます。
シナリオ: オンラインショッピングフォームでは、ユーザーは商品の選択、数量の入力、配送先の国の選択を行うことができます。 商品価格はフォームフィールドを通じて取得された固定値ですが、配送料は選択した国によって動的に異なります。
非表示のフィールドを含むフォームを乱雑にしないようにするために、企業は送料を一時的な変数に保存し、リアルタイムの計算に使用することを決定します。
ルールエディターで変数値を設定および変数値を取得する関数を使用した実装
変数の値を設定関数を使用してAddress フラグメントにルールを設定し、extrachargeという名前の一時変数を割り当てます。 この変数の値は、選択した国に応じて動的に変化します。 例:
- ユーザーが「米国」を選択した場合、extrachargeは500に設定されます。
- その他の国の場合、extrachargeは100に設定されています。
その後、合計出荷コストを計算すると、変数値の取得関数を使用して extracharge の値を取得します。 この値は 製品価格×製品数量 に追加され、ボタンをクリックすると最終的な支払い金額が計算されます。
「合計出荷コスト」フィールドは、ユーザーが国または数量を変更すると、製品コストと配送料の両方を反映するように動的に更新されます。
このアプローチにより、フォームに追加フィールドを追加することなく、動的なリアルタイムの計算が可能になり、構造をクリーンでユーザーフレンドリーに保つことができます。
カスタムイベントベースのルールサポート
拡張ルールエディターは、ディスパッチイベントおよび トリガーイベント 関数を使用したカスタムイベント処理をサポートしています。 これらの機能により、カスタムイベントを生成したりリッスンしたりすることで、フォームのさまざまな部分を通信できるようになり、特定のフィールドにアクションを緊密に結合することなく、よりクリーンでモジュール化されたロジックを実現できます。
シナリオ: Enter UsernameおよびEnter Password フィールドを含む再利用可能なログインフラグメントを使用して、ログインフォームが作成されます。 ユーザーが有効な資格情報を提供すると、フォームは入力を検証し、OTPを取得 プロセスを開始します。 ユーザーが有効なOTPを入力すると、適切なページにリダイレクトされます。
ロジックをフィールドに直接結合する代わりに、フォームは ディスパッチ イベント および トリガー イベント を使用したイベントベースのアプローチを使用して、モジュール性とメンテナンス性を向上させます。
ディスパッチ イベントとトリガー時イベントを使用した実装
ログインフラグメントがフォームに追加され、ユーザー名とパスワードの定義済みフィールドが含まれます。 OTPを取得 ボタンでルールが設定され、検証パネルが表示されます。このパネルには、OTPを入力および検証するための入力フィールドが含まれています。
検証パネルでは、「検証」ボタンにルールが設定されています。 API統合は、Enter OTP フィールドに入力されたOTPを検証するために使用されます。 検証が成功すると、LoggedInという名前の ディスパッチイベント が、API応答を含むイベントペイロードでトリガーされます。
フォームレベルでは、LoggedIn イベントをリッスンするようにルールが設定されています。 このイベントがトリガーされると、ルールはリダイレクトメッセージを表示し、ユーザーをダッシュボードページに移動します。
ユーザーが正しい資格情報と有効なOTPを使用してフォームを送信すると、ログインが成功し、ユーザーはダッシュボードにリダイレクトされます。
カスタムイベントのサポートにより、開発者がルールエディターで条件として使用できるカスタムイベントを作成およびトリガーできるようになりました。
OOTB イベントとカスタムイベントの簡略化された文法 simplified-grammar-for-ootb-and-custom-events
拡張ルールエディターには、ディスパッチイベントと トリガーイベント を使用するイベントベースのルール用の 簡略化された文法 が含まれています。 以前は、この文法はカスタム イベントにのみ適用されていました。標準提供(OOTB)イベントはサポートされていなかったため、多くの場合、OOTB トリガーにはWhen ルール、カスタムイベントにはOn トリガーイベント ルールが必要でした。 OOTB イベントは、同じ簡略化された文法でサポートされるようになりました。これにより、トリガーがOOTBであるかカスタムであるかに基づいて When と トリガーイベント を切り替えることなく、一貫したオーサリングパターンを実現できます。
繰り返し可能なパネルのコンテキストベースのルール実行
アダプティブ Formsは、繰り返し可能なパネルのコンテキストに応じたルールの実行をサポートします。 これにより、すべてのインスタンスに影響を与えたり、最後のインスタンスをデフォルトにしたりするのではなく、ユーザーが操作するパネルインスタンスに特化したルールを適用できます。
シナリオ:商品の注文フォームを使用すると、ユーザーは複数の商品を別々のパネルに追加できます。 各パネルには、製品の数 フィールドと合計コスト フィールドが含まれます。 ユーザーが製品の数量を更新すると、フォームは合計価格を再計算する必要がありますが、特定のパネルについてのみ再計算する必要があります。他のパネルについてはそうではありません。
ルールエディターでコンテキストに応じたルールを使用した実装
ルールは、繰り返し可能な製品パネル内の製品の数 フィールドに設定されます。
次のスクリーンショットは、繰り返し可能な製品パネル内の製品の数 フィールドのルールを示しています。
数量が変更されると、ルールは選択した製品の単価を取得し、そのパネルの合計原価のみを計算します。
ファイル添付ファイル コンポーネントと組み合わせたWhen条件 combined-when-conditions-with-the-file-attachment-component
拡張ルールエディターでは、ANDまたはOR ロジックを使用して、添付ファイル コンポーネントを他の条件と組み合わせるWhen ルールをサポートしています。 When句の Add Condition には、他のフィールドまたはパネル検証のチェックと共にファイル添付の状態を含めることができるため、選択したすべての条件が満たされた場合にのみアクションが実行されます。
シナリオ: ペット登録フォームは、ペット ID、ペット名、ペット カテゴリを収集し、写真を追加 ファイル添付ファイルを含みます。 フォームは、添付ファイルが および に変更された場合、他のフィールド(値)で設定された条件が満たされると、写真を追加をクリアまたは更新するアクションを実行します。
ルールエディターのファイル添付コンポーネントでWhen条件を使用した実装
ターゲットオブジェクトにルールが設定されています(写真を追加など)。 When セクションでは、Add Conditionを使用して、添付ファイルのトリガーを1つ以上の他のフィールドの条件と組み合わせます。そのため、操作は添付ファイルとフィールドの値の両方に依存します。
次のスクリーンショットは、複数の条件を含む When 条件と条件を追加 オプションを示しています。
When句が、設定済みの AND またはOR ロジックに対してtrueと評価される場合、ルールは設定済みアクションを実行します。
ペット IDに101が含まれている場合は、写真を追加の添付ファイルがクリアされます。同様に、ペット名にaが含まれている場合は、添付ファイルがクリアされます。
アダプティブ FormsのURLとブラウザーパラメーターベースのルール
アダプティブ Formsでは、フォーム URLを介して渡された外部パラメーターや、ユーザーのブラウザー環境から派生した外部パラメーターを使用して、動的なルールの実行をサポートします。 これにより、訪問者の流入元や使用しているデバイスにもとづいて、コンテキストに即してパーソナライズされたフォーム体験を提供できます。
許可されるパラメータータイプ
ref (文字列値のみ)?の後のURLの汎用キーと値のペア?ref=partner123UTM Medium
UTM キャンペーン
UTM条件
UTM コンテンツ
?utm_source=google&utm_medium=emailパス
hostname=www.example.com、path=/signupブラウザー言語
ブラウザープラットフォーム
Browser Agent=Mozilla、Language=en-USシナリオ: リードジェネレーションフォームは、トラフィックソースに応じてウェルカムメッセージをカスタマイズする必要があります。 ユーザーがGoogle広告キャンペーンを通じて(URLにutm_source=googleを使用して)フォームにアクセスすると、フォームにカスタムの挨拶が表示されます。
UTM パラメーターを使用した実装
ルールは、Google ユーザーにカスタムメッセージを表示するテキストフィールドに設定され、utm_source パラメーターを使用します。
次のスクリーンショットは、テキストメッセージで設定されたルールを示しています。
utm_source パラメーター値が「google」に等しい場合は、「Hello Google users, welcome to the Campaign Ad!」というカスタムメッセージが表示されます。 が表示されます。
これにより、マーケターは、入力したフィールドや独自のスクリプトを記述することなく、オーディエンスがフォームに入力したキャンペーンにもとづいて、最適なコンテンツを配信できます。
これらの機能強化により、アダプティブFormsのルールエディターの機能が大幅に強化され、開発者はより動的でインタラクティブでインテリジェントなフォームを作成するための強力なツールを利用できるようになります。 それぞれの機能強化は、技術的なユーザーと技術的なユーザーの両方がルールエディターにアクセスできる使いやすさを維持しながら、特定のビジネスニーズに対応しています。
その他のリソース
- コアコンポーネントに基づくアダプティブフォームのルールエディターの概要
- コアコンポーネントに基づくアダプティブフォームのルールエディターでの演算子のタイプとイベント
- コアコンポーネントに基づくアダプティブフォームのルールエディターのユーザーインターフェイス
- コアコンポーネントに基づくアダプティブフォームの様々なユースケース
- ルールエディターの様々なエディションの違い
- アダプティブフォームでの非同期関数の使用
- コアコンポーネントに基づくフォーム用のビジュアルルールエディターの呼び出しサービスの機能強化
- コアコンポーネントに基づくアダプティブフォームのカスタム関数の概要
- コアコンポーネントに基づくアダプティブフォームのカスタム関数の作成
- カスタム関数のスコープオブジェクト
- カスタム関数の開発と使用の例