Веб-каст про создание решений в SharePoint

На днях провел веб-каст для коллег с демонстрацией как можно создавать артефакты SharePoint в браузере и SharePoint Designer, а потом переносить их в Visual Studio для создания WSP.

Это мой первый опыт веб-каста, он записан в один заход и почти без предварительной подготовки. Прошу не судить строго.

 

Ссылки, используемые в веб-касте:



Процесс создания решений на SharePoint.

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

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

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

Когда топикстартеру задали вопрос зачем же все-таки так делать он ответил:

так задачу поставили( надо видеть количество страниц и переходы на них...

А дальше еще интереснее:

Руководство сказало "надо", мы сказали "есть!"))

Как ни парадоксально, но тем кто лучше всех должен разбираться в решениях на некоторой платформе совершенно все равно насколько полезны и эффективны их решения. Собственно само решение диктуется людьми (в данном случае “руководством”, иногда бывают аналитики или менеджеры), которые заведомо хуже в этом разбираются.

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

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

Но тут кому-то пришло в голову что там не хватает номеров страниц и перехода по ним. Попробуем разобраться откуда такая мысль.

Вариант первый

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

Скорее всего, именно из-за этих фич используется SharePoint, а не опенсорсная CMS. Но наличие таких фич  приводит к невозможности перехода к конкретной странице и подсчету их количества.

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

Создание такой системы – медвежья услуга.  Стандартные возможности SharePoint протестированы, документированы и работают. Создавая свое, похожее но другое, вы не можете вложить столько же сил в тестирование и документирование, сколько вложил Microsoft. Скорее всего решение будет работать гораздо хуже стандартного. Кроме того созданное решение надо поддерживать, апгрейдить итд.

Совокупная стоимость владения повышается, а эффект очень локален. Ведь новая система более привычна узкому кругу лиц.  Гораздо более правильное решение в данном случае – обучить пользоваться возможностями SharePoint.

Вариант второй

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

В этом случае правильное решение – настроить представления и\или поиск таким образом чтобы нужная информация была на первой странице.

Вариант третий

Кнопочки с номерами страниц – элемент визуального дизайна портала. Такое часто случается когда дизайн создается без оглядки на возможности SharePoint. То есть изначально полезности  в этом элементе нет, есть только визуальная “изюминка”.

В этом случае можно придумать другую “изюминку”. Например сделать unlimited scroll на странице списка. Такой элемент гораздо более удобен для пользователя, но при этом не требует подсчета количества страниц.

Заключение

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

PS. Этот вопрос подробно описан в книге Брукса Design of Design. Рекомендую всем к прочтению.



Другие 3 фичи SharePoint о которых не знает вообще никто

В предыдущем посте я рассказывал про малоизвестные фичи SharePoint. О них не написано в книгах, мало информации в MSDN и только в паре блогов можно прочитать о них хоть что-нибудь.

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

Третье место

Третье место в хит-параде занимают атрибуты Len и MoreText для элемента FieldRef во ViewFields в схеме CAML запроса (SPQuery). В документации эти атрибуты отсутствуют.  Если указать эти атрибуты для текстового поля, то SharePoint в этом поле вернет урезанную строку, которая вмещается в указанное в Len количество символов, в конце допишет текст, указанный в MoreText.
Причем обрезка текста происходит по границе слова, а не просто по количеству символов.  К сожалению не учитывается Html разметка.

Вот такой код:

using (var site = new SPSite("http://localhost"))
{
    var web = site.RootWeb;
    var list = web.GetList("Lists/Tasks");
    var query = new SPQuery()
    {
        ViewFields = "<FieldRef Name='Body' Len='20' MoreText='...'/>",
        ViewFieldsOnly = true
    };

    foreach (SPListItem item in list.GetItems(query))
    {
        Console.WriteLine(item["Body"]);
    }
}

Дает вот такой результат:

<div>Коллекции на вкладке...
<p>Коллекции на вкладке...
<div>Коллекции на вкладке...

Фича обнаружена Антоном Вишняковым (@avishnyakov).

Второе место

На втором месте находится простая и очень полезная фича. Если обработчик события элемента списка (event receiver) активировать в фиче уровня Site, то независимо от того к какому типу списка был привязан обработчик он будет срабатывать на каждом списке в коллекции сайтов. В том числе на User Information List хотя в MSDN явно написано что на этот список нельзя повесить обработчик. Таким образом можно отслеживать, например, добавление или удаление групп пользователей.
Возможно аналогичное будет работать и для других типов обработчиков событий.

Фича обнаружена Долгополовым Сергеем (http://www.facebook.com/serg3302).

Первое место

Очень простая и часто используемая фича. При развертывании файлов в виртуальной файловой системе с помощью модулей (Module) для элемента File можно указать атрибут DoGUIDFixUp=”TRUE”. Описание в MSDN крайне аскетично.

Если указать этот атрибут, то внутри самого файла и определения его веб-частей(если создается страница) все выражения вида {$ListId: WebRelativeListUrl;} будут заменяться на Guid_ы списка по указанному Url. Точка с запятой в конце Url обязательна. Естественно на момент развертывания указанный список должен существовать.

Как ни странно этот атрибут, видимо, существует еще с SharePoint 2007 и участвует в сохранении сайта в качестве шаблона. Так как при создании сайта из шаблона ID списков получаются новые, а многие компоненты SharePoint ссылаются на списки по ID. Но найти информацию мне не удалось.

Использование DoGUIDFixUp помогает деплоить workflow, веб-части и страницы с веб-частями.

На сладкое

Если вы используете DataFormWebPart (далее DFWP) для вывода данных с SharePoint помощью XSL и хотите создать веб-часть без серверного кода, то возникает проблема. SPDataSource, который используется для получения данных в DFWP, ищет список на текущем сайте.
Даже если, вы используя DoGUIDFixUp, корректно подставите ID списка на корневом сайте, то при размещении веб-части на дочернем сайте выпадет ошибка.

Оказывается если передать в SPDataSource параметр

<asp:Parameter Name="WebUrl" DefaultValue="{sitecollectionroot}"/>

то SharePoint будет искать список на корневом сайте.

Для примера я сделал проект со списком и веб-частью для отображения на основе DFWP абсолютно без кода.



3 фичи SharePoint о которых не знает почти никто

Private folder

Третье место в хит-параде почти неизвестных фич занимает каталог _private (начинается с символа подчеркивания) в виртуальной файловой системе SharePoint. Этот каталог находится в корне каждого узла и недоступен для внешнего HTTP запроса, только для API. Таким образом в этом каталоге можно хранить приватные данные, настройки и чтобы они не были доступны непривилегированным пользователям.

image

SPList.EnforceDataValidation

Второе место в хит-параде занимает это простое свойство, описание которого можно посмотреть по ссылке.
Если создать обязательное lookup поле, то в случае отсутствия элементов в lookup списке можно сохранить элемент с пустым значением lookup. Аналогичные проблемы можно получить и с другими полями если записывать данные в список с помощью SPWeb.ProcessBatchData. При SPList.EnforceDataValidation = true сам SharePoint дополнительно проверяет корректность данных.

Count related lookup

Первое место в хит параде достается особому типу lookup поля. Создав в списке A lookup колонку на список B можно потом создать в списке B lookup на список A. Это поле будет посчитывать количество связанных элементов.

image

image

Тоже самое доступно в API через свойство SPFieldLookup.CountRelated.

Далее еще 3 незвестные фичи.



Очередная встреча RUSUG 26.04.2012

Очередная встреча RUSUG состоится 26 апреля, в четверг. Пройдёт она, традиционно, в Технологическом центре компании Microsoft.

Первым докладчиком стану я, буду выступать с докладом «SharePoint Governance для разработчиков». В докладе пойдет речь о том как планировать, создавать и управлять решениями на SharePoint. Какие инструменты для этого есть в SharePoint, как их эффективно использовать и расширять.

Второй доклад будет посвящён лучшим практикам в настройке SQL Server для работы с SharePoint. Об этом расскажет Максим Хлупнов, Архитектор Технологического центра Microsoft.

Планируется проведение трансляции мероприятия, на которую необходима регистрация.

Регистрация на мероприятие и трансляцию: http://rusug.net/Lists/Apr2012Reg/NewForm.aspx