Как лучше всего использовать Tridion Broker в качестве единственного источника контента для нескольких веб-сайтов? - PullRequest
7 голосов
/ 22 марта 2012

Я работаю над реализацией Tridion, в которой есть несколько очень разных веб-сайтов, но часть контента (например, новости) предоставляется по базовому принципу разработки Tridion.Все сайты на одном языке, поэтому мы имеем дело только с различиями в брендинге.

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

Ситуация с брокером: Я хотел бы начать использовать брокера.Более того, поскольку в будущем веб-сайты также начнут предоставлять больше контента внешним веб-сайтам, что я собирался сделать с помощью RSS-каналов или базового API, который лучше всего работает с контентом от Брокера.

Сценарии:

  1. Разрешить этой публикации глобального контента публиковать динамический контент, а на других сайтах извлекать этот контент прямо из брокера (с глобальным идентификатором публикации контента?)
  2. Сделать поддельные пустые цели в глобальном контенте, чтобы они могли сказать «публиковать / отменять публикацию во всех дочерних публикациях?»(Вы все еще можете использовать флажки, чтобы разрешить его публикацию в определенных публикациях)
  3. Использовать веб-сайт глобального контента для публикации динамического контента и создавать каналы API / RSS для внутренних и внешних веб-сайтов для использования?
  4. Что-то еще?

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

Второй сценарий кажется вторым лучшим шансом.У кого-нибудь есть опыт такой реализации?

Ответы [ 2 ]

6 голосов
/ 22 марта 2012

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

Поскольку нам не хотелось, чтобы контент отображался в основной публикации веб-сайта (поскольку это никуда не денется и будет пустой тратой времени моего издателя на процессинг, а также тратой хранилища брокера при его развертывании ), мы создали ChildOnlyPublicationResolver (SDL Tridion 2011). В этом преобразователе мы перебираем все разрешенные элементы, и если элемент поступает из основной публикации веб-сайта, мы удаляем его из списка.

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

Если интересно, вот пример для кода решателя:

using System.Collections.Generic;
using Tridion.ContentManager;
using Tridion.ContentManager.Publishing;
using Tridion.ContentManager.Publishing.Resolving;

namespace SDL.Example.Resolvers
{
    public class ChildOnlyPublicationResolver : IResolver
    {
        /// <summary>
        /// Master Publication TCMURI
        /// </summary>
        private const string MasterPublicationTcmUri = "tcm:0-2-1";

        /// <summary>
        /// For publish and unpublish, remove all items from the master publication from the list.
        /// </summary>
        /// <param name="item">Item to be resolved (e.g. a page, structure group, template)</param>
        /// <param name="instruction">Resolve instruction</param>
        /// <param name="context">Publish context</param>
        /// <param name="resolvedItems">List of items that are currently to be rendered and published (added by previous resolvers in the chain)</param>
        public void Resolve(IdentifiableObject item, ResolveInstruction instruction, PublishContext context, Tridion.Collections.ISet<ResolvedItem> resolvedItems)
        {
            List<ResolvedItem> itemsToRemove = new List<ResolvedItem>();
            TcmUri masterPublicationUri = new TcmUri(MasterPublicationTcmUri);

            // check for items from master publication (these do not need to be published or unpublished)
            foreach (ResolvedItem resolvedItem in resolvedItems)
            {
                // mark all items from website structure publication for removal
                if (resolvedItem.Item.Id.PublicationId == masterPublicationUri.ItemId)
                {
                    itemsToRemove.Add(resolvedItem);
                }
            }

            // remove all items that we need to discard
            foreach (ResolvedItem itemToRemove in itemsToRemove)
            {
                resolvedItems.Remove(itemToRemove);
            }
        }
    }
}
2 голосов
/ 23 марта 2012

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

Как предположил Барт, в этом дизайне есть некоторые расточительные аспекты, поэтому вы можете подумать о том, что глобальный контент «объединяется» с одного веб-сайта.Для этого и предназначен веб-сервис доставки контента.Если вы работаете в Tridion 2011, вы можете эффективно выбрать свой вариант 3, но с большей встроенной поддержкой, чем раньше, поэтому вам не придется создавать API, просто используйте его.

...