Considérations relatives à l'architecture Sitecore 6.4 pour une solution ouverte à plusieurs sites et plusieurs langues?

Question

Je cherche à utiliser la nouvelle fonctionnalité de clonage de Sitecore 6.4 pour aider à la réutilisation des composants et du contenu pour une solution multi-site multilingue.

L'idée de base est de créer un référentiel de contenu central au sein de Sitecore (éventuellement en plusieurs langues) qui pourrait ensuite être cloné pour fournir des sites régionaux, chacun avec sa propre sélection de langues prises en charge. L'idée sous-jacente est de permettre aux régions de reproduire facilement le contenu dont elles ont besoin et d'en prendre possession. Avec le clonage, ils pourraient éditer les données là où ils le souhaitaient sans affecter les données sources, choisir d'omettre les éléments qui leur étaient étrangers (par exemple lorsqu'un produit n'était pas disponible dans leur pays), ajouter un nouveau contenu entièrement spécifique dans leur pays et traduire dans tous les dialectes régionaux qu'ils souhaitent soutenir (par exemple, le français suisse: fr-CH) etc.

L'ensemble de sites de base partagera une grande proportion de leurs données sources, bien que la plupart des versions linguistiques se produisent localement. .

Quelqu'un at-il une expérience avec ce type de déploiement Sitecore? Quels sont les pièges?

Cependant, une fois cette structure établie, le scénario à durée indéterminée entre en jeu. Nouveaux sites, par ex. un site de démarrage de lancement de produit, pourrait être ajouté à l'instance de Sitecore, et nous nous attendrions à ce que ceux-ci partagent du contenu, des modèles, une présentation, etc (si moins que les sites principaux).

Alors que le clonage permet la réplication de contenu avec la possibilité de modifier ce contenu dans son instance locale, j'essaie de trouver un moyen d'autoriser une procédure similaire pour les modèles. Est-il possible d'utiliser la fonction de modèle de base de l'héritage de modèle pour créer une couche de modèles «abstraits», qui serait instanciée dans des modèles concrets utilisés pour créer des éléments? Encore une fois, l'idée ici serait de permettre une flexibilité locale tout en partageant des fonctionnalités de base. Notre but serait de garder un ensemble propre de modèles abstraits et d'introduire seulement des modifications dans les versions instanciées localement de ceux-ci. Si tous les modèles dérivés d'un modèle abstrait nécessitaient un nouveau champ, cela pourrait être ajouté au niveau abstrait.

Nous espérons rester dans la mesure du possible avec la fonctionnalité prête à l'emploi de Sitecore.

Cette approche est-elle réalisable ou ai-je mélangé mes paradigmes? Quelles considérations dois-je avoir pendant que nous sommes encore en phase de pré-conception? Quel genre de règles de conception dois-je établir pour les développeurs?

Answer 1

Répondre à ma propre question, avec le crédit à John pour quelques pointeurs. Après quelques recherches, et les commentaires utiles laissés sur le forum SDN, il semble que cette approche est largement réalisable.

Avec les clones, il est possible de créer un référentiel de données central plutôt que de répliquer physiquement les données sur les sites qui le partageront. Il est également possible d'écraser des données dans un clone afin de fournir un contenu spécifique local. Cela peut être fait sur un champ par niveau de champ, de sorte qu'un champ d'un élément cloné reste hérité de son parent tandis qu'un autre est spécifique au site dans lequel le clone apparaît.

Ceci permettra aux sites locaux de répliquer la structure et la disposition du site par défaut tout en conservant une certaine souplesse par rapport à leurs propres exigences de contenu. Cela peut également être réalisé dans plusieurs langues.

MISE À JOUR: Un problème majeur non résolu est de savoir comment gérer les liens internes qui seront formatés en URL. Si un lien est inclus dans un champ de texte enrichi, par exemple, il référencera un GUID d'un élément. Une fois cloné, ce GUID sera le même, même s'il pointe vers la structure parente, et non vers la structure clone. Si vous modifiez le lien, la référence de clonage de ce champ sera rompue. Les mises à jour de l'élément parent ne seront donc pas répercutées sur le clone. Il n'existe pas de solution de contournement simple pour ce problème, bien qu'il soit possible d'étendre LinkManager pour rechercher une référence de clonage au lieu de simplement produire l'URL. Ceci est un inconvénient important, peut-être même un coup de projecteur. Il ne semble pas y avoir de moyen simple de mettre en œuvre de vrais modèles abstraits (ie pas de méthode de clonage pour les items) mais il serait possible de fournir une solution à mi-chemin basée sur un ensemble propre de modèles de base hérités par des versions locales. Le principal problème avec ceci serait que les éléments clonés seraient automatiquement associés aux modèles dont leurs parents ont été créés, plutôt qu'à une version locale. La modification des modèles d'éléments clonés vers une version locale serait possible (même si nous étions heureux de personnaliser la procédure de clonage de Sitecore). Sans automatisation, cela conduirait inévitablement à une maintenance accrue des sites et à la possibilité d'erreur de l'utilisateur. Comme les modèles locaux hériteraient toujours des modèles «abstraits» de base, nous serions en mesure d'implémenter des changements à tous les sites en modifiant le modèle abstrait. Un autre défi pour une telle architecture est de s'assurer que toutes les références des articles sont relatives, de sorte qu'un lien vers les produits sur chaque site mènera aux produits des sites, plutôt qu'aux données des produits définies dans le référentiel central. Les directives de conception pour les développeurs incluront une exigence selon laquelle tous les chemins d'accès aux sources de données sont directement configurables à partir de Sitecore (par exemple en utilisant le champ de source de données d'un rendu). Comme la fonction de clonage est encore relativement récente, il ne semble pas y avoir encore beaucoup d'expérience. Ce type de réutilisation des données est cependant la raison pour laquelle le clonage a été ajouté à Sitecore. Le principal écueil d'une telle approche semble être l'exigence d'évaluer pleinement l'impact de la conception sur différents sites locaux, ce qui accroît la complexité du développement et de la maintenance du code.

Answer 2

Certaines réponses sur le Sitecore Developer Network (SDN) forum thread.