При разработке пользовательских типов столбцов: Столбцы метаданных (часть 1, часть 2) и Расширенная подстановка (часть 1, часть 2) столкнулся с тем, что приходилось несколько раз обращаться к разным метаданным из разных узлов по разным их идентификаторам: тот же список однозначно определяется как по относительному сайта адресу (site-relative URL) так и по ID. А чтобы правильно получить его, соблюдая Рекомендации: использование высвобождаемых объектов служб Windows SharePoint Services, нужно указать идентификаторы семейства узлов и узла, которые тоже имеют свою разновидность.
Чтобы быть более сосредоточенным при разработке пользовательских типов столбцов именно на них, необходимо было отстраниться от этих навязывающихся дилемм.
Решение этих проблем было аккуратно упаковано во фреймворк по выборке метаданных SharePoint.
В разработке был задействован LINQ, поэтому данный фреймворк работает только при поддержке .NET Framework 3.5.
При поиске столбцов и представления списка играет роль чувствительность к регистру, в частности: web.Fields.GetFieldByInternalName(“Title”) – вернет столбец, а web.Fields.GetFieldByInternalName(“TITLE”) вернет null (если ранее не создавался столбец узла именно с таким внутренним именем). Если честно, то я так и не понял в чем собственно суть такого подхода, возможно, просто в самом ядре SharePoint, да и путаницу порой могут навести такие имена столбцов. Поэтому для таких случаев реализованы два метода: This() – не имеющий чувствительности к регистру и SPThis() – наоборот.
Кроме того, во фреймворке реализован поиск по параметрам, которые тоже являются уникальными для определения метаданных: URL представления списка; тип, внутреннее имя и FeatureId шаблона списков, но не используются методами поиска классов сборки Microsoft.SharePoint.
Есть, правда, в этом фреймворке одна тонкость: например, выражение SPMetadata.Site("http://localhost").Web("/test").List("/Lists/Tasks").This(); может вернуть null в трех случаях:
Чтобы быть более сосредоточенным при разработке пользовательских типов столбцов именно на них, необходимо было отстраниться от этих навязывающихся дилемм.
Решение этих проблем было аккуратно упаковано во фреймворк по выборке метаданных SharePoint.
В разработке был задействован LINQ, поэтому данный фреймворк работает только при поддержке .NET Framework 3.5.
При поиске столбцов и представления списка играет роль чувствительность к регистру, в частности: web.Fields.GetFieldByInternalName(“Title”) – вернет столбец, а web.Fields.GetFieldByInternalName(“TITLE”) вернет null (если ранее не создавался столбец узла именно с таким внутренним именем). Если честно, то я так и не понял в чем собственно суть такого подхода, возможно, просто в самом ядре SharePoint, да и путаницу порой могут навести такие имена столбцов. Поэтому для таких случаев реализованы два метода: This() – не имеющий чувствительности к регистру и SPThis() – наоборот.
Кроме того, во фреймворке реализован поиск по параметрам, которые тоже являются уникальными для определения метаданных: URL представления списка; тип, внутреннее имя и FeatureId шаблона списков, но не используются методами поиска классов сборки Microsoft.SharePoint.
Есть, правда, в этом фреймворке одна тонкость: например, выражение SPMetadata.Site("http://localhost").Web("/test").List("/Lists/Tasks").This(); может вернуть null в трех случаях:
- Отсутствие семейства узлов по заданному параметру siteID
- Отсутствие узла по заданному параметру webID
- Отсутствие списка узла по заданному параметру listID
Но в случае разработки данных типов столбцов это было не критично: если нет узла – значит, нет и списка, соответственно не с чем и работать.
Комментариев нет:
Отправить комментарий