JSSコード優先インポート・プロセスの特性
このページの翻訳はAIによって自動的に行われました。可能な限り正確な翻訳を心掛けていますが、原文と異なる表現や解釈が含まれる場合があります。正確で公式な情報については、必ず英語の原文をご参照ください。
コードファースト開発に使用されるJSSインポート プロセスを使用すると、Sitecoreから切断されている間にアプリケーションの構造を迅速に設計および定義し、それをSitecoreにパブリッシュできます。インポート プロセスでは、テンプレート、プレースホルダー設定、データソース アイテム、ルート アイテム、レンダリング アイテムなどのSitecoreアーティファクトが作成されます。
JSSアプリでApp Import機能を使用する場合は、次の点に留意する必要があります。
インポート プロセスはべき等です
インポート プロセスは、同じアプリケーションで同じSitecoreインスタンスに対して複数回実行できますが、いくつかの制限があります。
マニフェストで明示的に定義されていない項目のフィールドは、そのまま残ります。たとえば、Sitecore開発者がインポートされたフィールドにソースを入力した場合、マニフェストでソースの値も定義されていない限り、次のインポートではソースはリセットされません。
特別な考慮事項 は、インポートがコンテンツアイテムおよびコンテンツエディターとどのように機能するかを定義します。
インポート プロセスは、Sitecoreシリアル化に代わるものではありません
インポート形式は、Sitecoreアイテムの完全な忠実性を表しているわけではなく、アイテムを更新するときにすべての状況を処理するわけでもありません。これは、Sitecoreアイテムをシリアル化するUnicornやTDSなどのツールに代わるものではありません。
インポート プロセスでは、主に、利用可能なSitecoreインスタンスを持っていないフロントエンド開発者や、バックエンド開発者がSitecoreを設定する前にアプリケーションの作業を開始したいフロントエンド開発者がレンダリング アプリを設計できます。最終的には、開発プロセスでは、インポート プロセスを専用のSitecoreアイテム シリアル化ツールで補完するか、JSSアプリの状態を維持するために置き換えることをお勧めします (迅速に開発された単純なキャンペーン スタイルのアプリを除く)。
Sitecoreアイテムのシリアル化ツールは、JSSインポートによって作成または更新されたアイテムをシリアル化できます。これらは他のSitecoreアイテムと同じです。
インポート プロセスでは、既定では文字列がIDとして使用されます
インポート プロセスでは、文字列名がGUIDを持つSitecoreアイテムにマッピングされるため、インポート ファイルを簡単に記述できます。マッピングは、インポートされたアイテムの移動または名前の変更を慎重に行う必要があることを意味します。
インポートされたSitecoreアイテムIDは決定論的であり、同じアプリを異なるSitecoreインスタンスにインポートすると、Sitecoreに同じIDのアイテムが作成されます。
インポートしたアイテムの名前を変更する
これらは文字列名で一致するため、すでにインポートされた後にマニフェスト (またはSitecore) でアイテムの名前を変更すると、インポートが再実行されると重複するアイテムが作成されます。アイテムの重複を防ぐには:
-
マニフェストIDをSitecoreの既存のインポート済みアイテムIDに明示的に設定し、マニフェストで名前を変更します。インポート時に名前が変更されます。
-
表示名を設定し、名前をそのままにしておくと、Sitecoreで名前が視覚的に変更されます。
インポートしたアイテムの移動
これらは名前で一致しているため、インポートされたアイテムを移動すると、次回のインポート時に重複が発生します。
インポートしたアイテムを移動する必要がある場合は、マニフェストで既にインポートされたSitecoreアイテムIDと同じアイテムの明示的なIDを設定します。インポート プロセスでは、名前ではなくIDでアイテムをクエリします。したがって、アイテムは移動後もマニフェストに認識されたままになります。
インポート プロセスでは、不明なアイテムはパージされません
マニフェストからテンプレートまたはルートを削除した場合、インポート プロセスでは、次回のインポート時にSitecoreからは削除されません。
インポート プロセスでは、明示的に定義されたマニフェスト データに対してのみ値が設定されます
明示的に定義されたマニフェスト データのみが、Sitecoreで設定された値を上書きします。
たとえば、アイコンを定義しないテンプレートをインポートし、Sitecore開発者がアイテムにアイコンを設定したとします。この場合、今後のインポートではアイコン値は上書きされません。マニフェストでテンプレートのアイコンが定義されている場合、マニフェストの値によってSitecoreで設定された値が上書きされます。
インポートプロセスでのアイテムIDの取り扱い
Sitecoreアイテムには一意のGUID IDがあります。既定では、App Importはマニフェストで定義されているnameを使用して 決定論的なGUIDを派生させ、インポートされたアイテムが常に予測可能なIDを持つようにします。GUIDはnamespacedであるため、名前はJSSアプリ全体ではなく、アプリのセクション内でのみ一意である必要があります。
たとえば、ルートとHomeという名前のテンプレート (または異なるレベルの2つのルート) の両方を持つことは有効ですが、Homeという2つのテンプレートを持つことは無効です。名前空間にはJSSアプリケーション名も含まれているため、複数のJSSアプリケーションに同じ名前の項目を含めることができます。
JSSアプリケーションの名前を変更すると、その項目の予期されるGUIDがすべて変更されます。
また、アイテムのマニフェスト定義にidプロパティを追加することで、インポート マニフェスト内のすべてのアイテムのexplicit IDを指定することもできます。
多言語インポート環境でルートデータに明示的なIDを指定する場合は、すべての言語値で同じID値であることを確認してください。
idは、次のいずれかのタイプになります。
-
GUID値 (文字単位で使用されます)。これは、Sitecoreで使用されているものと同じアイテムIDです。
-
決定論的なGUIDのソースとして使用される文字列値。名前ベースの決定論的GUIDとは異なり、explicit string IDs are namespaced only by the JSS app name.したがって、JSSアプリ内でグローバルに一意である必要があります。
アプリのインポートでは、データの損失を避けるために、インポートされた既存のアイテムのGUIDは変更されません。すでにインポートされたアイテムにID値を設定すると、そのアイテムを削除してインポートを再実行するか、インポートをfull wipeモードで実行した場合にのみ、新しいIDがSitecoreで有効になります。
サンプル・アプリケーションのStyleguideの例には、content reuseのStyleguideの例に明示的なIDを設定する例があります。
マニフェストにcomponentsを追加する場合は、renderingIdとthe templateIdの2つのidプロパティを指定する必要があります。JSSコンポーネント定義は2つのSitecoreアイテムを追加するため、両方が存在する必要があります。