Где создавать статьи в Sitecore?

Question

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

В основном я рассматриваю 2 варианта: 1 - Создайте статью в виде страницы; 2 - Создайте статью как элемент данных сайта.

1 - Создайте статьи на данной странице (т. Е. Мои статьи). Таким образом, каждая статья будет иметь конкретный URL-адрес из коробки, более понятный в контексте Авторы содержания;

2 - Указать определенную папку (то есть папку со статьей) в разделе Данные сайта. Таким образом, нам не нужно иметь страницу для каждой статьи - я думал, что у меня есть одна страница статьи, которая будет отображать поля статьи. Однако для этого потребуется больше работы с точки зрения URL-адресов, навигации и т. Д.

Есть ли другие идеи? Я что-то упускаю? Я также иметь взгляд на Ковши ...

Спасибо

Answer 1

Я буду не согласен с Мареком и рекомендуем вам выбрать вариант 2.

Сохранение ваших статей в папке под узлом Data позволяет эти элементы должны быть datasourced. Это был принцип Sitecore. Затем вы можете нарисовать эти статьи несколькими интересными способами через Widgets, такие как Promo Panels, предлагая пользователю щелкнуть, чтобы прочитать статью, не дублируя ее данные и требуя, чтобы Content Editors управляли данными несколько раз.

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

Как вы заявляете, это потребует дополнительной работы с точки зрения адресов и навигации, но это может быть достигнуто с помощью Wild Card Item Sitecore, и вы даже используете отличный модуль с открытым исходным кодом от Marketplace Sitecore, чтобы выполнить 90% работы за вас , См. Ссылки ниже для получения дополнительной информации.

Вы по-прежнему можете использовать точку Марека для применения информации о представлении один раз на стандартных значениях элемента Wild Cart, который вы создаете. Если вы используете Sitecore 7 и выше, вы можете хранить все свои статьи в Bucket, поэтому, если у вас есть много статей, они хранятся и доступны для поиска значимым образом.

• http://www.sitecore.net/learn/blogs/technical-blogs/getting-to-know-sitecore/posts/2011/09/wildcards-and-data-driven-urls.aspx
• https://marketplace.sitecore.net/en/Modules/Wildcard_module.aspx

Answer 2

Go с подходом 1: статья страницы.

Определите все ваши данные для презентации на Article Page template __Standard Values. Все новые статьи получат их. И вы можете изменить некоторые детали презентации для выбранных вами статей, если хотите.

Если вы знаете, что у вас будет много статей, подумайте о структуре папки , например. articles/2015/06/12.

Подход 2 не дает вам ничего - вы все равно должны иметь предмет для каждой статьи. И, как вы писали, для этого потребуется дополнительное кодирование, которое не требуется.

Answer 3

В стандартной конфигурации один экземпляр самый простой реализации заключается в создании статей, как страницы.

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

Это приводит тогда вы нуждаясь в структуру папок и пара вариантов:

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

2. Используйте ведро, которое автоматически создает структуру папок и скрывает эту сложность от редактора содержимого. Это приводит к созданию и обслуживанию папки вручную из редактора содержимого и автоматически создается на основе конфигурации, установленной для вашего ведра. Папки не будут отображаться в редакторе содержимого, поэтому они будут вынуждены искать в корзине любые статьи, а не перемещаться по папкам. (https://marketplace.sitecore.net/en/Modules/News_mover.aspx). Для этого требуется другой подход. Он работает через традиционную структуру папок, однако он создает папки и перемещает элемент на сохранение в соответствии с полем даты в статье. Таким образом, новостной движок обрабатывает генерацию папок, однако вам все равно нужно снова проверить не более 100 элементов на каждую папку для повышения производительности при открытии папок с большим количеством элементов.

Со всеми решениями вы все равно должны учитывать URL-адреса для своих статей, так как они будут включать структуру папок по умолчанию. Это не всегда приемлемо. Я предпочитаю удалить структуру папок из URL. Для этого вам нужно создать собственный linkProvider и пользовательский HttpRequestProcessor. Во-первых, linkprovider позволяет вам гарантировать, что новый URL-адрес всегда создается и отображается на вашем сайте по своему усмотрению. Далее HttpRequestProcessor гарантирует, что при навигации по сокращенному URL Sitecore распознает его как действительный URL-адрес и представляет правильную страницу.

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

Answer 4

Модель данных чистых данных предназначена для использования подстановочного подхода для URL-адресов и централизации хранения данных статей в ведре источников данных. Это даст вам оптимальную производительность и повторное использование данных.

Однако это не то, как автор думает о своем веб-сайте. Когда они используют систему, они стремятся перейти к области, где они будут просматривать статьи, и попытаться создать там новую. Авторы склонны думать на «страницах», поэтому старайтесь скрыть любую модель данных, которую вы используете, и дайте им возможность редактировать страницу с помощью Редактора опыта.

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

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