ブロックの作成、更新、リファクタリング block-development

Experience Modernization Agentは、継続的なEdge Delivery Services開発および移行に使用します。 作成者のニーズと実際のコンテンツから始めて、それらをサポートする最小の実装を選択します。

この作業では、エージェントはコンテンツ駆動開発（CDD）に従います。 実際のコンテンツと作成者が作成する方法から始まり、その後にコードを記述します。 これにより、制作者はコンテンツモデルを容易に利用できるようになり、開発者のみが入力できるブロックを回避することができます。

目的のリポジトリとブランチを接続し、変更権限を確認して、コンテンツが保存されている場所を特定します。 共有コードやコンテンツモデルを変更する前に、ベースラインを維持しましょう。

ブロックを作成する前に作成 composition

HTML要素は、見出し、段落、リンク、リスト、画像などの基本的な構成要素です。 作成者は、可能な限り、デフォルトコンテンツ（ブロック外のコンテンツ）を使用する必要があります。 グローバルスタイルやCSS カスタムプロパティ、デザイントークンを使用して、共有タイポグラフィ、色、間隔、リンク/ボタンの表示を定義できます。

ブロックを使用すると、作成者は、一連のカードやカルーセルなど、周囲のデフォルトコンテンツとコードが区別できない1つのコンポーネントを構成するコンテンツをマークできます。 サイトが提供するHTMLでは、ブロックはブロック名をクラスとして持つdivです。 プロジェクトのblocks/<name>/<name>.jsとblocks/<name>/<name>.cssがブラウザーで装飾されます。 コードがデフォルトコンテンツのパターンを認識できる場合は、ブロック自体を構築できます。aem.liveは自動ブロック ​を呼び出します。例えば、AEM ボイラープレートは、/widgets/ ページへのリンクをウィジェットブロックに変換します。 軽量で焦点を合わせたブロックを維持します。 視覚的な違いだけでは、新しいブロックは必要ありません。CSSとJavaScriptはデフォルトコンテンツにスタイルを設定でき、バリエーションやセクションスタイルには違いがあります。

Davidのモデル ​は、作成者が簡単に作成できるコンテンツのaem.live ルールを収集します。デフォルトコンテンツを好み、ブロック内のブロックを避け、ブロックとバリエーションの数を少なくし、ボタンが含まれているブロックまたはセクションからスタイルを取得できるようにします。 ブロックが​ ブロックコレクション ​のジョブと同じジョブを実行する場合は、そのブロックのコンテンツモデルを再利用します。

コードを生成する前に、プロジェクトの規則を確認します。

Edge Delivery Servicesには、ボタングループや脚注コントロールが組み込まれていません。 それぞれの規則は、プロジェクトのコードがオーサリングされたコンテンツに適用される規則です。プロジェクトがどのように実装しているかを確認し、レンダリング結果をテストします。

例：アトミックブロックを含まない柔軟なティーザー composition-example

コンポーネントベースのAdobe Experience Manager プロジェクトでは、作成者がそれらを組み合わせることができるように、ティーザーコンポーネント（見出し、画像、テキスト、ボタンの各コンポーネント）が提供されることが多くあります。 例えば、WKND サンプルサイト ​のホームページでは、コアコンポーネントティーザーを使用して各旅行を宣伝しています。 Edge Delivery Servicesを使用すると、作成者は、セクションまたはブロックセルに、デフォルトコンテンツと同じエレメントを直接書き込みます。

[Image]
## Downhill Skiing Wyoming
A skier's paradise far from crowds and close to nature.
**[View trip](/adventures/downhill-skiing-wyoming)**
_[All adventures](/adventures)_

現在のAEMのボイラープレート ​では、段落に1つしかないリンクは、プライマリボタンの場合は太字、セカンダリボタンの場合は斜体、アクセントボタンの場合は太字+斜体の形式でボタンになります。 プレーンリンク、または文内のリンクは、リンクのままです。 グローバルスタイルを使用すると、これらのボタンはデフォルトコンテンツとブロック内で同じ外観になります。

作成者は、新しいコンポーネントを使用せずに、見出し、テキスト、画像、リンクを追加、削除、並べ替えることができます。 ティーザーやヒーローブロックは、作成者が一緒に属する要素をマークする必要がある場合にのみ必要です。CSSとJavaScriptでは、デフォルトコンテンツのテキストの横に画像を配置することもできます。 プロジェクトはこれらの規則を変更できるため、エージェントに頼む前に、プロジェクトのスクリプトとスタイルを確認するように依頼します。

ブロックのプロンプト block-prompts

「顧客の声ブロックを作成する」などの短いプロンプトから始めることができます。 エージェントが特定の何かに一致するのに役立つコンテキストを追加します。

リファレンスページまたはスクリーンショットは、ターゲットの外観を示します。 制作者が何を編集したかを定義するわけではないので、そのように言うこともできます。

既存のブロックの再利用 reuse-blocks

エージェントがブロックを作成する前に、プロジェクトのblocks フォルダーで、参照コードの​ ブロックコレクション ​および​ ブロックパーティ ​で、再利用または適応するブロックを探します。 移行時に、​ ブロックライブラリ ​がある場合にもチェックされます。

ブロックを1つずつ作成する iterate-blocks

複数のブロックが必要な場合は、ひとつのプロンプトですべてのブロックを要求しないでください。 最初に1つまたは2つの代表的なブロックを構築し、コンテンツモデル、スタイル、オーサリングを確認します。 その後、他のグループと続けて、名前、バリエーション、間隔などの決定が引き継がれます。 移行では、残りのテンプレートの前に1つの代表テンプレートのブロックを生成して検証します。一括読み込みワークフローを参照してください。

移行前のブロック動作の設定 block-instructions

移行は、ソースページで見つかったコンテンツからブロックを生成します。 エージェントがブロックを生成する前に、ブロックの作成方法を制御するには、次の手順を実行します。

自動モードでは、実行時に指示を受けません。 その後、コンソールでブロックを調整します。

ブロックを作成 create

作成者タスク、コンテンツの例、必要な動作とデザイン、​ コンテンツが保存されている場所、およびテストページを指定します。

次に例を示します。

ドキュメントベースのページ用に顧客の声のブロックを作成します。 次の実際のコンテンツの例から開始：/aboutと/customers。 まず既存のブロックをチェックします。 作成者は、レイアウト設定なしで、見積もり、属性、オプションの画像を編集する必要があります。 トークンを使用します。 長いテキストと画像なしの例を含めます。 アップロード、プッシュ、または公開しないでください。

例のパスを独自のパスに置き換えます。

その結果、再利用可能なコード、作成者が必要とするモデル、作成者が編集できるコンテンツの例が得られます。

エージェントがブロックで提供するもの block-deliverables

既存のブロックの更新 update

ブロック名、現在の例/バリエーション、要求された変更、および互換性の要件を指定します。

次に例を示します。

cardsを更新して、承認されたセカンダリリンクのバリアントが/productsと/blogで機能するようにします。 既存のデフォルトバリエーションと画像バリエーションおよびオーサリングコンテンツを保持。 キーボード操作とモバイルラッピングを確認します。 他のページを書き換えたり、コンテンツをアップロードしたりしないでください。

例のパスを独自のパスに置き換えます。

変更された動作、影響を受けるバリエーション、作成者の指示、必要なコンテンツの変更を引き継ぎます。

結果を変更せずにリファクタリング refactor

リファクタリングは、合意された行動を維持しながら実装を改善するのに役立ちます。 カタログの再グループ化、ブロックの再設計、コンテンツモデルの移行とは異なります。

次に例を示します。

blocks/cards/cards.jsとblocks/teaser/teaser.jsで重複したカード装飾ロジックをリファクタリングします。 オーサリングモデル、出力セマンティクス、アピアランス、リンク動作、キーボードアクセス、分析フックを保持します。 回帰の例として/productsと/blogを使用します。 互換性リスクを報告し、テスト結果を報告します。 コンテンツを移行したり、変更をプッシュしたりしないでください。

例のパスを独自のパスに置き換えます。

別のリファクタリング コマンドはありません。チャットで尋ねると、設定した制限内で開発者が行うようにエージェントがコードを変更します。

ダイナミックブロックの作成 dynamic-blocks

動的ブロックは、制作者が書いた内容だけを表示するのではなく、ブラウザーでコンテンツを読み込むか計算します。 例としては、最新の記事のリスト、検索結果、フィルター付きリストなどがあります。 エージェントに、他のブロックと同様に移行後に1つ作成するか、移行後のブロックを変更して、この方法で作業するように依頼します。 説明：

次に例を示します。

画像、タイトル、日付を含む、サイトのクエリインデックスの6つの最新の記事を表示する記事リストブロックを作成します。 作成者は、キー値テーブルにリストする記事の数とフォルダーを設定します。 記事がない場合は短いメッセージを表示します。 /newsでテストします。 アップロード、プッシュ、または公開しないでください。

クエリインデックスには、公開されたページのみが含まれ、設定が抽出するプロパティのみが含まれているため、テストする前に両方を確認してください。 空の状態とエラーの状態、および通常の結果を検証します。

サービスとアプリケーションの接続 integrations

担当者は、サイトを他のシステム（アドオンでカバーできないシステムを含む）に接続するためのコードを記述します。 Edge Delivery Services以外の作業では、統合を使用して作業する方法について説明します。 このセクションでは、そのコードが実行される場所について説明します。

Edge Delivery Servicesでは、訪問者のブラウザーでこのコードが実行されるため、各接続はブロック、ウィジェット、またはプロジェクトのスクリプトの一部となります。 エージェントがキーを必要とするAPIを呼び出す必要がある場合は、チャットではなく​ 設定 ​でキーを追加します。

アドオンは、タスクに必要なときにエージェントが有効にする​ オプション機能です。 どのシステムがつながり、誰が所有し、その結果を受け入れるのかが、プロジェクトの意思決定となります。 残りのプロジェクト作業を参照してください。

フォームの送信 form-submissions

Edge Delivery Servicesはフォームを配信しますが、送信された内容を保存したり、その後に続く処理を実行したりすることはありません。 ソースサイトでは、サーバーが各送信を処理し、ページの読み込みはそのサーバーを見ることができません。 宛先の接続は、移行されたかどうかにかかわらず、Edge Delivery Services サイトで同じ作業です。エージェントは汎用コーディングエージェントであるため、いつでも依頼できます。

Forms アドオンの機能 forms-add-on

フォームアドオンは、Adobe Experience Manager Formsのライセンスを取得している企業向けに構築されています。 Experience Manager Forms🔗用にEdge Delivery Servicesのフォームを準備します。 2つ以上のフィールドを持つソースフォームごとに、フォーム定義のフィールドが記録されます。フィールドごとに1つの行（名前、ラベル、タイプ、オプション、検証）を持つページの横に保存されたシートが記録されます。 次に、定義にリンクするページにフォームブロックを配置します。 フィールドとラベルはその定義のコンテンツであり、フォームバックエンドに保持されるデータではありません。 すべてのフォームは、formという名前の同じブロックを使用し、その定義によって表示される内容が決まります。したがって、エージェントはブロックのバリエーションを作成しません。 アドオンは、ソースフォームにちなんで名前が付けられたページのフォルダーに各定義を保存し、他のページで同じフォームを検索しません。 複数のページが一箇所に表示されるフォームを管理するには、担当者にページを単一の定義にリンクするように依頼します。

プロジェクトにまだフォームブロックがない場合、アドオンはExperience Manager Formsのフォームブロックを追加します。 このブロックは、すべての送信をForms送信サービス ​に送信します。この送信サービスは、フォームを定義のパスで識別し、定義の送信行にリンクされたスプレッドシートにデータを保存します。 アドオンはスプレッドシートをリンクせず、またソースフォームが送信したアドレスも保持しないので、フォームが公開される前に宛先を接続します。 宛先の選択を参照してください。 アドオン自体にはライセンスは必要ありませんが、フォームブロックとForms Submission ServiceにはExperience Manager Forms ライセンスが必要です。

Experience Manager Formsがない場合、アドオンのフィールドインベントリは、各フォームのフィールド、ラベル、タイプ、オプション、検証をキャプチャするのに役立ちます。 担当者には他のフォームプラットフォームのスキルがないので、Edge Delivery Services以外の作業で説明しているように、最初にプラットフォームのドキュメントを読んでください。 その後、同じ定義を読み取り、プラットフォームに送信するフォームブロックを作成したり、プラットフォームがホストするフォームを埋め込んだりできます。

アドオンは、ソースサーバーが送信するHTMLから各フォームを読み取ります。これには、サードパーティプロバイダーのフォームがHTMLに存在する場合も含まれます。 マーケティングプラットフォームから埋め込まれたフォームなど、スクリプトがブラウザーに追加するフォームは、そのHTMLにはないため、アドオンは読み込みません。 そのフォームを再構築するか、プラットフォームからもう一度埋め込むようにエージェントに依頼します。

宛先の選択 form-destination

リードフォームは、マーケティングオートメーションプラットフォームや顧客関係管理（CRM）システムなど、リードを既に処理している場所に属します。

複数のシステムに送信する必要がある場合は、Adobe Workfront FusionやMicrosoft Power Automateなどの統合プラットフォームや独自のAPIに送信します。 Experience Manager Formsを使用すると、Forms Submission Serviceは提出物をスプレッドシートに保存したり、電子メールで送信したり、Experience Managerで実行される提出物アクションをMarketo Engage、Workfront Fusion、Power Automate、REST エンドポイントなどの他のシステムに転送したりします。 送信アクションの設定を参照してください。

これらのプラットフォームの多くは、秘密鍵を必要としないフォームエンドポイントで、ブラウザーからの送信を受け入れます。 プラットフォームのAPIにキーが必要な場合は、上記の​ Secrets ​で説明されているように、それを保持するサーバーサイドサービスを通じて送信します。

担当者に伝える：

次に例を示します。

最初に、https://developer.example.com/formsでのフォーム送信に関するCRMのドキュメントを読みます。 次に、/contactのフォームをhttps://forms.example.com/submit/contact-usのCRM フォーム contact-usに接続します。 名、姓、電子メール、会社、国をCRM フィールド FirstName、LastName、Email、Company、およびCountryにマッピングします。電子メールと会社が必要です。 リードソース「Web サイト」、ページ URL、訪問のUTM パラメーターの非表示フィールドを追加します。 「製品ニュースを電子メールで受け取ることに同意します。」チェックボックスをオフにして、この同意を表示します。 送信が成功したら、「ありがとうございます、私たちは連絡を取ります」と表示します。送信が失敗した場合は、訪問者の入力を保持し、再試行でエラーを表示します。 https://sandbox.example.comでCRMのサンドボックスに対してテストします。 アップロード、プッシュ、または公開しないでください。

例のURL、名前、文言を独自のURLに置き換えます。

エージェントは、フォーム定義とフォームブロックのコードを更新します。 また、チームがシークレットを使用してデプロイするサーバーサイドサービスのコードを記述することもできます。 受信プラットフォームでは、管理者は次のように設定します。

プレビューサイトからテストエントリを送信します。 すべてのフィールドに到着し、想定されるワークフローを開始し、テストとしてマークされていることを確認します。 切り替え後に実稼動ドメインのチェックを繰り返します。

Commerce ページ commerce-pages

コマースページのアドオンは、Adobe Commerce ストアフロントのExperience Modernization Agentのページ読み込みワークフローを拡張します。 ソースサイト上の商品詳細ページと商品リストページを、商品構造化データ、URL パターン、数量フィールド、商品グリッド、フィルターなどのページ要素などのシグナルから、どのプラットフォームが実行していても認識できます。 コマースブロックでは商品のSKU、つまりカテゴリのパスのみを保持し、標準ブロックではバナーやプロモーションなどの周囲のコンテンツを保持するページとして再構築します。 商品データは読み込まれません。コマースブロックは、訪問者がページを開くたびにカタログから商品データを読み込みます。 エージェントは、標準ワークフローで他のページを移行します。

アドオンがコマースブロックを記述することはありません。 プロジェクトが既に持っている製品ブロックとリストブロックを使用します。それ以外の場合は、​ コマースストアフロントボイラープレート ​のproduct-details ブロックとproduct-list-page ブロックが想定されます。 そのボイラープレートからプロジェクトを開始し、ストアフロントをカタログに接続して、読み込まれたページで商品を確認したときに商品が表示されるようにします。 アドオン自体にはライセンスは必要ありませんが、ストアフロントのドロップインコンポーネントにはAdobe Commerce as a Cloud ServiceまたはAdobe Commerce Optimizer ライセンスが必要です。 Adobe Commerce Optimizerは、他のコマースプラットフォームがカート、チェックアウト、注文を処理する際に、カタログを提供することもできます。 ​ バックエンドオプション ​を参照してください。

Adobe Commerce Optimizerがない別のコマースプラットフォームの場合、アドオンは適用されません。 担当者は、プラットフォームのAPIからデータを読み込む製品ブロックとリストブロックを作成し、Edge Delivery Services以外の作業で説明されているように、プラットフォームのドキュメントから作業します。

このアドオンは、​ ドキュメントベースのコンテンツ ​で動作します。 Experience Manager オーサリング ​を使用するプロジェクトの場合、エージェントは標準の移行を使用します。この移行では、各製品ページに表示されているものをインポートします。 ページとカタログの連携方法を決定します。

検証と配信 validation

プロジェクトで宣言されているlint コマンドとtest コマンドを使用し、ブラウザーが実際のコンテンツをチェックします。 単にテストしただけではなく、コマンドと結果を報告するようにエージェントに依頼します。

チェック項目:

チェックが失敗した場合は、失敗した例を保持し、影響を受ける最小のレイヤーを修正します。 古いプレビュー/コードブランチの問題を、モデルまたは実装の失敗と区別します。 失敗したチェックと関連するリグレッションを再実行します。

差分を確認し、目的のファイルのみをステージングし、リポジトリポリシー🔗を プッシュします。 テストコンテンツまたは実稼動コンテンツは、許可された場合にのみアップロードします。コードプッシュでは保存されません。 mainに結合すると、ブロック コードは、ブロックを使用するライブサイト上のすべてのページに適用されます。変更内容の公開方法を参照してください。

回復するには、Git経由でコードを元に戻し、変更されたリモートコンテンツを個別に復元します。 必要なコンテンツの移行が受け入れられるまで、互換性のある古い例を保持します。

​ プロジェクトの引き継ぎを使用して、変更されたファイル、モデル、例、検証結果、残りのリスク、次のユーザーまたはエージェントの回復方法を保持します。