複数サイト、多言語のオープンエンドソリューションのためのSitecore 6.4アーキテクチャに関する考慮事項？

Question

Sitecore 6.4の新しいクローン機能を使用して、複数サイトの多言語ソリューションのコンポーネントとコンテンツの再利用を支援したいと考えています。

基本的な考え方は、Sitecore内に（場合によっては複数の言語で）中央のコンテンツリポジトリを作成し、それを複製してそれぞれがサポートされている言語を選択できる地域サイトを提供できるようにすることです。この背後にある考え方は、地域が必要なコンテンツを簡単に複製して所有権を得ることを可能にすることです。クローニングを行うことで、ソースデータに影響を与えずに必要な場所でデータを編集したり、関連のない項目（たとえば、製品が自国で利用できなかった場所など）を除外したり、

ほとんどの言語バージョンがローカルで発生しても、サイトのコアセットはそのソースデータの大部分を共有します（たとえば、フランス語：fr-CHなど）。 。

誰かがこの種のSitecore展開について経験を積んでいますか？落とし穴は何ですか？

ただし、この構造が確立されると、オープンエンドシナリオが再生されます。新しいサイト（例：製品の起動スプラッシュサイトであるSitecoreインスタンスがSitecoreインスタンスに追加される可能性があり、コンテンツ、テンプレート、プレゼンテーションなどを共有することが期待されます（ただし、コアサイトよりもはるかに少ない）。

クローン作成では、ローカルインスタンスのコンテンツを変更する可能性のあるコンテンツの複製が可能ですが、テンプレートに対して同様の手順を実行する方法を見つけることを試みています。テンプレート継承の基本テンプレート機能を使用して、抽象的なテンプレートのレイヤーを作成することは可能ですか？アイテムを作成するために使用される具体的なテンプレートでインスタンス化されますか？ここでも、コア機能を共有しながらローカルな柔軟性を持たせることが考えられます。私たちの目的は、抽象的なテンプレートのクリーンなセットを保持し、ローカルにインスタンス化されたバージョンの変更のみを導入することです。抽象テンプレートから派生するすべてのテンプレートが新しいフィールドを必要とする場合、これは抽象レベルで追加することができます。

できるだけ早くSitecoreにそのまま残しておきたいと考えています。

このアプローチはすべて実行可能ですか、私のパラダイムが混ざっていますか？私たちはまだ設計段階に入っていますが、どのような配慮が必要ですか？開発者にはどのようなデザインルールを設定する必要がありますか？

Answer 1

私の自身の質問に答えるために、いくつかのポインタのためにJohnにクレジットを与えてください。

SDNフォーラムに残されたいくつかの調査や有益なコメントの後、このアプローチは大いに実行可能であるようです。

クローンを使用すると、データを共有するサイトにデータを物理的に複製するのではなく、中央のデータリポジトリを作成することができます。ローカルの特定のコンテンツを提供するために、クローン内のデータを上書きすることもできます。これは、フィールドレベルでフィールドで行うことができます。クローンアイテムの1つのフィールドは、親から継承され、別のフィールドはクローンが表示されるサイトに固有のフィールドです。

これにより、ローカルサイトは、独自のコンテンツ要件に対する柔軟性を維持しながら、デフォルトサイトの構造とレイアウトを複製できます。これは、複数の言語にわたって達成することもできます。

更新：重要な問題の1つは、URLにフォーマットされる内部リンクの処理方法です。たとえば、リンクがリッチテキストフィールドに含まれている場合、リンクはアイテムのGUIDを参照します。複製された場合、このGUIDは、クローン構造ではなく親構造を指しても同じです。リンクを編集すると、そのフィールドのクローン参照が破損するため、親アイテムの更新はクローンにプッシュされません。この問題の簡単な回避策はありませんが、単純にURLを生成するのではなく、LinkManagerを拡張してクローン参照を参照することは可能です。これは重大な欠点であり、おそらくはショーストッパーでさえあります。

真の抽象テンプレートを実装する簡単な方法はないようです（つまり、アイテムのようなクローニング方法はありません）が、引き継ぐことができるきれいな基本テンプレートに基づいて半分の解決策を提供することは可能でしょう地元のバージョンで。この主な問題は、複製されたアイテムが、ローカルバージョンではなく、親が作成されたテンプレートに自動的に関連付けられることです。クローン化されたアイテムテンプレートをローカルバージョンに変更することも可能です（Sitecoreのクローニング手順をカスタマイズすることができれば自動化さえも可能です）。自動化がなければ、必然的にサイトのメンテナンスの増加とユーザーエラーの可能性があります。ローカルのテンプレートは引き続きベースの「抽象」テンプレートから継承されるため、抽象テンプレートを変更することですべてのサイトの変更を実装できます。

このようなアーキテクチャのさらなる課題は、すべてのアイテム参照が相対的であることを保証することです。各サイトの製品へのリンクは、セントラルリポジトリに設定された製品データセットではなく、開発者向けのデザインガイドラインには、データソースへのすべてのパスを（たとえば、レンダリングのデータソースフィールドを使用するなどして）Sitecoreから直接設定できるという要件が含まれています。

クローニング機能はまだ比較的新しいので、まだ多くの経験があるようには見えません。しかし、このようなデータの再利用は、Sitecoreにクローニングが追加された理由です。

このようなアプローチの主な落とし穴は、さまざまな地元のサイトに対する設計の影響を完全に評価する必要があるようであり、開発とコードメンテナンスの複雑さが増します。

Answer 2

Sitecoreデベロッパーネットワーク（SDN）forum threadにいくつかの回答があります。