design architecture sitecore sitecore6

design - Consideraciones para la arquitectura de Sitecore 6.4 para múltiples sitios, solución abierta de múltiples idiomas?



architecture sitecore6 (2)

Respondiendo mi propia pregunta, con crédito a John por algunos consejos.

Después de algunas investigaciones, y los útiles comentarios que dejaron en el foro de SDN, parece que este enfoque es en gran medida viable.

Con los clones es posible crear un repositorio de datos central, en lugar de replicar físicamente los datos en los sitios que lo compartirán. También es posible sobrescribir datos en un clon para proporcionar contenido local específico. Esto se puede hacer en un campo por nivel de campo, de modo que un campo de un elemento clonado permanezca heredado de su padre mientras que otro sea específico del sitio en el que aparece el clon.

Esto permitirá que los sitios locales repliquen la estructura y el diseño del sitio predeterminado a la vez que mantienen la flexibilidad sobre sus propios requisitos de contenido. Esto también se puede lograr en múltiples idiomas.

ACTUALIZACIÓN: Un problema importante no abordado es cómo manejar los enlaces internos que se formatearán en las URL. Si se incluye un enlace en un campo de texto enriquecido, por ejemplo, hará referencia a un GUID de un elemento. Cuando se clona este GUID será el mismo, aunque apunta a la estructura padre, no a la estructura clónica. La edición del enlace romperá la referencia de clonación para ese campo, por lo que las actualizaciones del elemento principal no se transferirán al clon. No hay una solución simple para este problema, aunque podría ser posible extender el LinkManager para buscar una referencia de clonación en lugar de simplemente producir la URL. Esto es un inconveniente importante, posiblemente incluso un inconveniente.

No parece haber una manera simple de implementar plantillas abstractas verdaderas (es decir, no hay un método de clonación como para los artículos) pero sería posible proporcionar una solución a mitad de camino basada en un conjunto limpio de plantillas base que podrían ser heredadas por las versiones locales. El principal problema con esto sería que los elementos clonados se asociarían automáticamente con las plantillas a partir de las cuales se crearon sus padres, en lugar de una versión local. Cambiar las plantillas de elementos clonados a una versión local sería posible (incluso automatizable siempre que estuviéramos satisfechos con la personalización del procedimiento de clonación de Sitecore). Sin automatización, esto llevaría inevitablemente a un mayor mantenimiento de los sitios y la posibilidad de error del usuario. Como las plantillas locales seguirían heredando de las plantillas "abstractas" básicas, podríamos implementar cambios en todos los sitios alterando la plantilla abstracta.

Un desafío adicional para dicha arquitectura es garantizar que todas las referencias de los artículos sean relativas, de modo que un enlace a los Productos en cada sitio conduzca a los Productos de los sitios, en lugar de los datos de los Productos en el repositorio central. Las pautas de diseño para desarrolladores incluirán un requisito de que todas las rutas a las fuentes de datos se pueden configurar directamente desde Sitecore (por ejemplo, mediante el uso del campo fuente de datos de una representación).

Como la función de clonación aún es relativamente nueva, no parece que haya mucha experiencia con ella todavía. Sin embargo, este tipo de reutilización de datos es la razón por la que se agregó la clonación a Sitecore.

El principal inconveniente de tal enfoque parece ser el requisito de evaluar completamente el impacto del diseño en diferentes sitios locales, lo que lleva a una mayor complejidad de desarrollo y mantenimiento del código.

Estoy buscando utilizar la nueva funcionalidad de clonación de Sitecore 6.4 para ayudar con la reutilización de componentes y contenido para una solución de múltiples idiomas y sitios múltiples.

La idea básica es crear un repositorio central de contenido dentro de Sitecore (posiblemente en varios idiomas) que luego podría clonarse para proporcionar sitios regionales, cada uno con su propia selección de idiomas admitidos. El pensamiento detrás de esto es permitir que las regiones repliquen fácilmente el contenido que requieren y se apropien de él. Con la clonación, podrían editar los datos donde lo requerían sin afectar los datos de origen, optar por omitir los elementos que eran irrelevantes para ellos (por ejemplo, cuando un producto no estaba disponible en su país), agregar contenido nuevo que fuera completamente específico a su país y traducir a los dialectos regionales que deseaban apoyar (por ejemplo, francés suizo: fr-CH), etc.

El conjunto principal de sitios compartirá una gran proporción de sus datos de origen, aunque la mayoría de las versiones de idioma se producen localmente.

¿Alguien ha tenido alguna experiencia con este tipo de implementación de Sitecore? ¿Cuáles son las trampas?

Una vez que se estableció esta estructura, sin embargo, el escenario de final abierto entra en juego. Es posible que se agreguen sitios nuevos, por ejemplo, un sitio de lanzamiento de productos, a la instancia de Sitecore, y esperamos que compartan contenido, plantillas, presentaciones, etc., cuando corresponda (aunque en un grado mucho menor que los sitios principales).

Si bien la clonación permite la replicación de contenido con la posibilidad de modificar ese contenido en su instancia local, estoy tratando de encontrar la forma de permitir un procedimiento similar para las plantillas. ¿Es posible usar la función de plantilla base de la herencia de la plantilla para crear una capa de plantillas "abstractas", que se instanciaría en plantillas concretas utilizadas para crear elementos? Nuevamente, la idea aquí sería permitir la flexibilidad local mientras se comparte la funcionalidad central. Nuestro objetivo sería mantener un conjunto limpio de plantillas abstractas y solo introducir modificaciones en las versiones localmente instanciadas de ellas. Si todas las plantillas derivadas de una plantilla abstracta requieren un nuevo campo, entonces esto podría agregarse al nivel abstracto.

Esperamos permanecer dentro de la funcionalidad de Sitecore en la medida de lo posible.

¿Es este enfoque viable, o he mezclado mis paradigmas? ¿Qué consideraciones debería tener mientras todavía estamos en la fase de pre-diseño? ¿Qué tipo de reglas de diseño necesito establecer para los desarrolladores?