注意事项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.
这套核心站点将分享thier源数据的很大比例，但与大多数的语言版本在本地存在的。
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的实例，我们希望这些共享内容，模板，presentation等，其中appropiate（虽然以一个远较小的程度比芯的网站）。
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.
我们希望留withing Sitecore的开箱即用的功能尽可能地。
We hope to stay withing Sitecore out of the box functionality as far as possible.
是这种方法在所有可行的，或者已经跟我混我的范式？我应该有什么样的考虑，而我们仍然在pre-设计阶段非常？我需要什么样的设计规则，建立开发者？
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?
推荐答案
回答我的问题，以信誉约翰一些三分球。
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.
有这种结构的另一个挑战是，以确保所有项目的引用是相对的，以便向产品的链接在每个站点上会导致该部位的产品，而不是产品数据在中央储存库设置。为开发设计准则将包括要求对数据源的所有路径都从内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.
这种方法的主要缺陷似乎是全面评估设计对不同的本地站点的影响的要求，从而提高开发和code维护的复杂性。
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屋！
