Соображения для архитектуры Sitecore 6.4 для нескольких сайтов, решение для нескольких языков с открытым концом?

Question

Я смотрю на использование новых функций клонирования Sitecore 6.4, чтобы помочь в повторном использовании компонентов и контента для нескольких сайтов и нескольких языковых решений.

Основная идея - создать центральный репозиторий контента в Sitecore (возможно, на нескольких языках), который затем может быть клонирован для предоставления региональных сайтов, каждый из которых имеет собственный выбор поддерживаемых языков. Мысль об этом заключается в том, чтобы позволить регионам легко тиражировать требуемый контент и владеть им. С клонированием они смогут редактировать данные там, где они требуются, не затрагивая исходные данные, оставлять без внимания элементы, которые не имеют к ним отношения (например, когда продукт не был доступен в их стране), добавить новый контент, который был полностью конкретным к их стране и перевести на любые региональные диалекты, которые они хотели бы поддержать (например, швейцарский французский: fr-CH) и т. д.

Основной набор сайтов будет разделять большую часть исходных данных, хотя большинство языков, ,

Есть ли у кого-нибудь опыт такого развертывания Sitecore? Каковы подводные камни?

Как только эта структура была установлена, однако, сценарий открытой игры входит в игру. Новые сайты, например. сайт запуска запуска продукта, может быть добавлен в экземпляр Sitecore, и мы ожидаем, что они будут совместно использовать контент, шаблоны, презентацию и т. д., где это приемлемо (хотя и в гораздо меньшей степени, чем основные сайты).

В то время как клонирование позволяет реплицировать контент с возможностью изменения этого содержимого в его локальном экземпляре, я пытаюсь найти способ разрешить подобную процедуру для шаблонов. Можно ли использовать базовый шаблон функции наследования шаблонов для создания слоя «абстрактных» шаблонов, который будет создан в конкретных шаблонах, используемых для создания элементов? Опять же, идея здесь заключалась бы в обеспечении локальной гибкости при совместном использовании основных функций. Наша цель состояла бы в том, чтобы содержать чистый набор абстрактных шаблонов и вводить модификации только в локально-инстанцированных версиях. Если для всех шаблонов, полученных из абстрактного шаблона, требуется новое поле, это можно добавить на абстрактном уровне.

Мы надеемся, что, насколько это возможно, оставайтесь с Sitecore.

Является ли этот подход совершенно работоспособным или я смешал свои парадигмы? Какие соображения я должен иметь, пока мы все еще находимся на стадии предварительного проектирования? Какие правила дизайна мне нужно установить для разработчиков?

Answer 1

Отвечая на мой собственный вопрос, с благодарностью Джону за некоторые указатели.

После некоторых исследований и полезных комментариев, оставленных на форуме SDN, кажется, что этот подход в значительной степени работоспособен.

С помощью клонов можно создать центральный репозиторий данных, а не физически реплицировать данные на сайты, которые будут совместно использовать его. Также можно перезаписать данные в клоне, чтобы обеспечить локальный специфический контент. Это можно сделать в поле по уровню поля, так что одно поле клонированного элемента остается унаследованным от его родителя, а другое - для сайта, на котором появляется клоун.

Это позволит локальным сайтам реплицировать структуру и макет сайта по умолчанию, сохраняя при этом гибкость в отношении собственных требований к контенту. Это также может быть достигнуто на нескольких языках.

ОБНОВЛЕНИЕ: Одной из основных проблем, которые не рассматриваются, является обработка внутренних ссылок, которые будут отформатированы для URL-адресов. Например, если ссылка включена в текстовое поле с расширенным текстом, она будет ссылаться на идентификатор GUID элемента. При клонировании этот GUID будет таким же, хотя он указывает на родительскую структуру, а не на структуру клонирования. Редактирование ссылки приведет к разрыву ссылки на клонирование для этого поля, поэтому обновление родительского элемента не будет перенесено в клон. Для этой проблемы нет простого решения, хотя можно было бы расширить LinkManager для поиска ссылки на клонирование вместо простого создания URL-адреса. Это существенный недостаток, возможно даже шоустоппер.

Существует не какой-либо простой способ реализации истинных абстрактных шаблонов (т. Е. Никакого метода клонирования, как для элементов), но можно было бы предоставить решение на полпути на основе чистого набора базовых шаблонов, которые могли быть унаследованы по местным версиям. Основная проблема заключается в том, что клонированные элементы будут автоматически связаны с шаблонами, из которых были созданы их родители, а не с локальной версией. Изменение клонированных шаблонов элементов в локальной версии было бы возможно (даже автоматизировано, если бы мы были довольны настройкой процедуры клонирования Sitecore). Без автоматизации это неизбежно приведет к увеличению обслуживания сайтов и возможности ошибки пользователя. Поскольку локальные шаблоны все еще наследуются от базовых «абстрактных» шаблонов, мы могли бы реализовать изменения ко всем сайтам, изменив абстрактный шаблон.

Еще одна проблема для такой архитектуры - обеспечить, чтобы все ссылки на элементы относительны, так что ссылка на Продукты на каждом сайте приведет к тому, что на этом сайте будут размещены Продукты, а не данные Продуктов, установленные в центральном репозитории. Рекомендации по разработке для разработчиков будут включать требование о том, чтобы все пути к источникам данных напрямую настраивались из Sitecore (например, используя поле источника данных для рендеринга).

Поскольку функция клонирования по-прежнему относительно новая, похоже, что пока нет большого опыта. Однако этот тип повторного использования данных является причиной того, что клонирование было добавлено в Sitecore.

Основным недостатком такого подхода является требование полной оценки влияния дизайна на различные локальные сайты, что приводит к повышенной сложности разработки и обслуживания кода.

Answer 2

Некоторые ответы на сеть разработчиков Sitecore (SDN) forum thread.