多站点、多语言开放式解决方案的 Sitecore 6.4 架构的注意事项? [英] Considerations for Sitecore 6.4 architecture for multiple site, multiple language open ended solution?

问题描述

我正在考虑使用 Sitecore 6.4 的新克隆功能来帮助为多站点、多语言解决方案重用组件和内容.

I'm looking at using the new cloning functionality of Sitecore 6.4 to help with reuse of components and content for a multiple site, multiple language solution.

基本思想是在 Sitecore 内创建一个中央内容存储库(可能有多种语言)，然后可以将其克隆以提供区域站点，每个站点都有自己选择的受支持语言.这背后的想法是允许区域轻松复制他们需要的内容并拥有它的所有权.通过克隆，他们将能够在不影响源数据的情况下在他们需要的地方编辑数据，选择忽略与他们无关的项目(例如，产品在他们的国家/地区不可用)，添加完全特定的新内容到他们的国家并翻译成他们希望支持的任何区域方言(例如瑞士法语:fr-CH)等.

The basic idea is to create a central content repository within Sitecore (possibly in multiple languages) which could then be cloned to provide regional sites, each with their own selection of supported languages. The thinking behind this is to allow regions to easily replicate the content they require and take ownership of it. With cloning they would be able to edit the data where they required without affecting the source data, choose to leave out items which were irrelevant to them (e.g. where a product wasn't available in their country), add new content that was entirely specific to their country and translate into any regional dialects they wished to support (e.g. Swiss French: fr-CH) etc.

核心网站集将共享大部分源数据，尽管大多数语言版本控制发生在本地.

The core set of sites will share a large proportion of thier source data, though with most language versioning occuring locally.

有人对这种 Sitecore 部署有任何经验吗?有哪些陷阱?

Has anyone got any experience with this sort of Sitecore deployment? What are the pitfalls?

然而，一旦建立了这种结构，开放式场景就开始发挥作用了.新网站，例如一个产品发布启动站点，可能会添加到 Sitecore 实例中，我们希望这些站点在适当的情况下共享内容、模板、演示等(尽管程度远低于核心站点).

Once this structure was established, however, the open-endedness scenario enters play. New sites, e.g. a product launch splash site, might be added to the Sitecore instance, and we would expect these to share content, templates, presentation etc where appropiate (though to a far lesser degree than the core sites).

虽然克隆允许复制内容并有可能在其本地实例中修改该内容，但我试图找到一种方法来允许对模板执行类似的过程.是否可以使用模板继承的基本模板特性来创建一层抽象"模板，这些模板将在用于创建项目的具体模板中实例化?同样，这里的想法是在共享核心功能的同时允许本地灵活性.我们的目标是保持一组干净的抽象模板，并且只在它们的本地实例化版本中引入修改.如果从抽象模板派生的所有模板都需要一个新字段，则可以在抽象级别添加该字段.

While cloning allows replication of content with the possibility of modifying that content in its local instance I'm trying to find a way to allow a similar procedure for templates. Is it possible to use the base template feature of template inheritance to creat a layer of "abstract" templates, which would be instantiated in concrete templates used to create items? Again, the idea here would be to allow local flexibility while sharing core functionality. Our aim would be to keep a clean set of abstract templates and only introduce modifications in locally instantiated versions of them. If all templates deriving from an abstract template required a new field then this could be added at the abstract level.

我们希望尽可能继续使用 Sitecore 开箱即用的功能.

We hope to stay withing Sitecore out of the box functionality as far as possible.

这种方法是否可行，或者我是否混合了我的范例?当我们仍处于预设计阶段时，我应该考虑哪些因素?我需要为开发者建立什么样的设计规则?

Is this approach at all workable, or have I mixed my paradigms? What considerations should I have while we're still very much in pre-design phase? What sort of design-rules do I need to establish for developers?

推荐答案

回答我自己的问题，感谢 John 的一些建议.

Answering my own question, with credit to John for some pointers.

经过一些研究以及 SDN 论坛上留下的有用评论，看来这种方法在很大程度上是可行的.

After some research, and the helpful comments left on the SDN forum, it seems this approach is largely workable.

通过克隆，可以创建一个中央数据存储库，而不是将数据物理复制到将共享它的站点.还可以覆盖克隆中的数据以提供本地特定内容.这可以逐个字段级别完成，以便克隆项的一个字段保留从其父项继承，而另一个字段特定于出现克隆的站点.

With clones it is possible to create a central data repository, rather than physically replicating the data to the sites that will share it. It is also possible to overwrite data in a clone in order to provide local specific content. This can be done on a field by field level, so that one field of a cloned item remains inherited from its parent while another is specific to the site in which the clone appears.

这将允许本地站点复制默认站点的结构和布局，同时保持其自身内容要求的灵活性.这也可以跨多种语言实现.

This will allow local sites to replicate the structure and layout of the default site while maintaining flexibility over their own content requirements. This can also be achieved across multiple languages.

更新:一个未解决的主要问题是如何处理将被格式化为 URL 的内部链接.例如，如果链接包含在富文本字段中，它将引用项目的 GUID.克隆时，此 GUID 将相同，即使它指向父结构，而不是克隆结构.编辑链接将破坏该字段的克隆引用，因此对父项的更新不会被推送到克隆.这个问题没有简单的解决方法，尽管可以扩展 LinkManager 以查找克隆引用而不是仅仅生成 URL.这是一个明显的缺点，甚至可能是个大问题.

UPDATE: One major problem not addressed is how to handle internal links that will be formatted to URLs. If a link is included in a rich text field, for example, it will reference a GUID of an item. When cloned this GUID will be the same, even though it points back to the parent structure, not to the clone structure. Editing the link will break the clone reference for that field, so updates to the parent item won't be pushed through to the clone. There is no simple workaround for this problem, though it could be possible to extend the LinkManager to lookup a clone reference instead of merely producing the URL. This is a significant drawback, possibly even a showstopper.

似乎没有任何简单的方法来实现真正的抽象模板(即没有项目的克隆方法)，但是可以提供基于一组干净的基本模板的中途解决方案，这些模板可以被继承本地版本.这样做的主要问题是克隆项目会自动与创建其父项的模板相关联，而不是本地版本.将克隆的项目模板更改为本地版本是可能的(甚至可以自动化，前提是我们对自定义 Sitecore 克隆过程感到满意).如果没有自动化，这将不可避免地导致站点维护增加和用户出错的可能性.由于本地模板仍会从基本的抽象"模板继承，我们将能够通过更改抽象模板来对所有站点进行更改.

There doesn't seem to be any simple way of implementing true abstract templates (i.e. no cloning method as for items) but it would be possible to provide a halfway solution based on a clean set of base templates that could be inherited by local versions. The main problem with this would be that cloned items would automatically be associated with the templates their parents were created from, rather than a local version. Changing cloned item templates to a local version would be possible (even automatable provided we were happy with customising the Sitecore cloning procedure). Without automation this would inevitably lead to increased maintenance of the sites and the possibility of user error. As the local templates would still inherit from the base "abstract" templates we would be able to implement changes to all sites by altering the abstract template.

这种架构的另一个挑战是确保所有项目引用都是相对的，以便每个站点上的 Products 链接将指向该站点的 Products，而不是中央存储库中的 Products 数据集.开发人员的设计指南将要求所有数据源路径都可直接在 Sitecore 内进行配置(例如通过使用渲染的数据源字段).

A further challenge for such an architecture is to ensure that all item references are relative, so that a link to Products on each site will lead to that sites Products, rather than the Products data set in the central repository. Design guidelines for developers will include a requirement that all paths to data sources are directly configurable from within Sitecore (such as by using the data source field of a rendering).

由于克隆功能仍然相对较新，因此似乎还没有太多的经验.然而，这种类型的数据重用是将克隆添加到 Sitecore 的原因.

As the cloning feature is still relatively new it doesn't seem like there is much experience with it as yet. This type of data re-use is, however, the reason cloning was added to Sitecore.

这种方法的主要缺陷似乎是需要全面评估设计对不同本地站点的影响，从而导致开发和代码维护的复杂性增加.

The main pitfall of such an approach appears to be the requirement to fully assess the impact of design on varying local sites, leading to increased complexity of development and code maintenance.

这篇关于多站点、多语言开放式解决方案的 Sitecore 6.4 架构的注意事项?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！