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

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

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

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

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

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

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

Мы надеемся, насколько это возможно, использовать стандартную функциональность Sitecore.

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


person James Walford    schedule 17.01.2011    source источник
comment
Этот вопрос может получить больше активности на форуме SDN. Кроме того, вы смотрели на Sitecore Foundry? Это может лучше подходить для вашей ситуации со многими сайтами.   -  person Mark Ursino    schedule 17.01.2011
comment
Спасибо, да, я тоже собирался опубликовать это там, хотя в прошлом у меня были хорошие отзывы о Sitecore. Я еще раз взгляну на Foundry и посмотрю, есть ли у него функции, которые сделают этот проект подходящим.   -  person James Walford    schedule 17.01.2011
comment
Нет ответа ни здесь, ни на форуме SDN - я плыву в неизведанные воды?   -  person James Walford    schedule 21.01.2011


Ответы (2)


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

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

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

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

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

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

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

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

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

person James Walford    schedule 07.02.2011
comment
У нас есть тяжелый опыт работы с функцией клонирования, из-за которой мы не хотим прикасаться к ней снова, если это вообще возможно. +1 за ваш ответ, поскольку вы объяснили некоторые проблемы, с которыми мы также сталкивались в прошлом. - person chenz; 23.02.2012
comment
Нам тоже было нелегко. Большая часть проблемы на самом деле не техническая (хотя несколько ошибок в ранней системе клонирования вызывали проблемы), а в том, что конечные пользователи не могут понять систему. Трудно объяснить им концепцию и трудно упростить так, чтобы им не нужно было ее понимать. - person James Walford; 23.02.2012

Некоторые ответы в сети разработчиков Sitecore (SDN) ветке форума.

person John West    schedule 21.01.2011