Какое убийственное использование типов контента для списков (не библиотек документов)?

Question

Я видел много блогов, статей и дискуссий в Интернете, которые наводят меня на мысль, что пользовательские типы контента являются обязательной функциональностью на сайте SharePoint, особенно в том, что касается настройки без кода на сайтах SharePoint / MOSS. .

Однако, после нескольких часов направленного исследования по этому вопросу, использование типов контента (для списков, а не для библиотек документов) не кажется мне настолько впечатляющим:

• (1) Я могу сгруппировать похожие типы записей (например, Задачи и Вехи) в одном и том же Списке и назначить пользовательский набор полей (и различные варианты в этих полях) для каждого типа записей в Списке.
• например. тип содержимого задачи может иметь поле «Назначено» и поле «Состояние», варианты которого включают «Не начато, Выполняется, Выполнено, Отказано»; тип содержимого Milestone может пропустить поле «Назначено» и предоставить поле «Состояние» с вариантами «Не завершено, Завершено, Отказано».
• Однако почему бы просто не создать отдельные списки? Одна из причин группировки разных типов контента в один список состоит в том, что вы можете создать один рабочий процесс и заставить его обрабатывать все типы контента в этом списке. Если бы у вас было два отдельных списка, вам пришлось бы дважды создавать рабочий процесс и поддерживать любые обновления в двух местах - большая боль в заднице.
• (2) Когда у меня есть разные наборы полей для каждого типа контента, SharePoint автоматически генерирует разные формы «Новый элемент» и «Редактировать элемент» для каждого - только показывая / запрашивая поля, которые действительно относятся к одному типу контента или другой.
• например. Когда я создаю новый элемент «Задача», форма ввода, созданная SharePoint, автоматически включает поле «Назначено»; когда я создаю новый элемент Milestone, форма ввода, создаваемая SharePoint, не включает поле «Назначено», что упрощает его для пользователей (и обеспечивает чистоту данных).
• (3) Рабочие процессы для каждого типа содержимого - хотя рабочие процессы могут быть связаны только с одним списком, вы также можете связать рабочий процесс с типом содержимого. Это дает вам две возможности:
• Создайте другой рабочий процесс с различными действиями и условиями, подходящими для каждого типа контента.
• Создайте один рабочий процесс, который работает с одним типом контента, и используйте этот тип контента в нескольких списках. (Затем вы получаете «один и тот же рабочий процесс в нескольких списках», с определенной точки зрения на вещи.)
• (4) Я могу создать запись определенного типа в Списке, а затем настроить все так, чтобы все записи этого «типа» были доступны только для чтения (т.е. их нельзя редактировать после их создания).
• (5) Фильтрованные поиски: http://www.sharepointblogs.com/mossms/archive/2009/07/23/filtered-lookups-across-content-types.aspx

Я что-то упустил? Есть ли какой-то сценарий использования пользовательских типов контента в списках, который я не вижу, и который делает их обязательной для вас функцией SharePoint для вас?

Answer 1

Точки, которые Дженис и Алекс подчеркивают, хорошие. Вот несколько моих собственных:

1. Хорошая аналогия, которую рисует Янис. Типы контента - это не просто данные - это поведение, которое соответствует этим данным. Эта «переносимость поведения» позволяет нам перестать думать о данных SharePoint как о том, что они просто сидят в списке. Привязанность к списку особенно ограничивает; типы содержимого нарушают это ограничение.

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

3. Что мне особенно нравится в типах контента (связанных с переносимостью поведения), так это возможность указывать пользовательские формы для просмотра и работы с данными. Я не говорю о FormTemplates , которые подключаются к страницам формы списка; Я говорю о собственном опыте. Весь «ориентированный на список» образ мышления SharePoint можно перевернуть с помощью хорошо продуманных форм, которые связаны с помощью элементов FormUrl , указанных в структуре XmlDocument типа содержимого. Пустая страница ASPX становится вашим холстом, если вы этого хотите.

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

Вот только один пример: MOSS Records Center. «Внутренности» Центра записей MOSS используют типы контента в качестве механизма маршрутизации и сортировки, чтобы упростить жизнь (http://blogs.msdn.com/recman/archive/2006/09/12/750034.aspx). Если у вас много данных без классификаций типов контента и вы решили использовать Центр записей. .. ой.

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

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

Я мог бы продолжить, но, надеюсь, это даст вам представление о том, что типы контента могут сделать для вас как для разработчика, так и для администратора. Вам, конечно, не нужно для их использования, но они представляют собой значительное улучшение по сравнению со днями данных, относящихся к списку, в WSSv2 / SPS 2003.

За что это стоит!

Answer 2

Я вижу их как классы. Почему бы не классифицировать ваши данные?

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

Answer 3

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

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

Это также хороший знак того, что тот, кто разработал решение, уделил некоторое внимание планированию и согласованию бизнес-требований с продуктом. В противном случае может указывать на то, что существует тенденция создавать списки ad hoc, которые часто могут стать кошмаром обслуживания.