SharePoint для профессионалов

Реализация паттерна UniqueURLs в SharePoint

2012-05-30T09:00:00.000+04:00

На своем докладе на MsDevCon’12 я рассказывал о нескольких паттернах, и в частности — о паттерне Unique URLs. Также, я показывал, как этот паттерн работает на реальном примере – созданном мной Ajax-дашбоарде. Этот паттерн крайне актуален для Ajax-приложений, и строится вокруг следующего утверждения:

У каждого состояния страницы должен быть уникальный адрес

Это означает, что когда вы нажимаете на некой странице на кнопку или ссылку, и состояние (внешний вид) страницы меняется (неважно, был ли это postback или callback) — то у этой страницы должен измениться и адрес (т.е. текст в строке браузера):

Если каждый раз адрес менять не получается (например, в случае карт), то нужно предусмотреть кнопку «Получить ссылку» или что-то в этом духе.

Естественно, что если другой пользователь, или этот же, но позже — переходит по ранее запомненному уникальному адресу, то состояние страницы должно восстановиться:

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

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

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

В частности, в SharePoint «из коробки» уже подключена библиотека ASP.Net Ajax версии 3.5, и оказывается, в этой библиотеке есть встроенные средства для реализации якорной навигации, что нам вполне подходит. На MSDN есть статья Managing Browser History Using Client Script, которая объясняет, как работать с якорной навигацией с помощью ASP.Net Ajax.

Если вкратце, потребуется всего два метода:

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

Но при корректном использовании этой связки двух методов, в SharePoint’е всплывает небольшая проблема... А именно, перестает работать переключение локализации «на лету». Возможно, также перестают работать и какие-то другие функции – точно не знаю. Немного покопавшись в отладчике, я выяснил, что проблема зарылась в функции OnSelectionChange:

function OnSelectionChange(value) {
    var today = new Date();
    var oneYear = new Date(today.getTime() + 365 * 24 * 60 * 60 * 1000);
    var url = window.location.href;
    document.cookie = "lcid=" + value + ";path=/;expires=" + oneYear.toGMTString();
    window.location.href = url;
}

Здесь присваивание window.location.href = url; должно по идее вызывать перезагрузку страницы, но т.к. на конце url при использовании анкорной навигации идет символ решетка (“#”) и параметры, идентифицирующие текущее состояние страницы (например, “http://site/page.aspx#state=10”), то перезагрузки страницы не происходит, т.к. браузер думает, что мы хотим перейти на анкор внутри текущей страницы.

Довольно забавный баг, но неприятный. Вышеозначенная функция “OnSelectionChange” генерируется прямо в код страницы, непосредственно перед кодом риббона. Редиску, которая генерирует эту функцию, я вычислять не стал. Вместо этого, просто исправил в ней ошибку и теперь переопределяю её после начальной загрузки страницы.

В конечном итоге, класс, ответственный за реализацию Unique URLs в моем проекте, выглядит следующим образом:

/// <reference path="GridController.js" />
DW.TasksDashboard._UniqueURLs = function () {

    DW.TasksDashboard.DataLoadManager.add_dataLoaded(onDataLoaded);

    this.FixOnFlyLocalization = function () {
        window.OnSelectionChange = function (value) {
            var today = new Date();
            var oneYear = new Date(today.getTime() + 365 * 24 * 60 * 60 * 1000);
            var url = window.location.href.replace(/#[^#]*$/, '');
            document.cookie = 'lcid=' + value + ';path=/;expires=' + oneYear.toGMTString();
            window.location.href = url;
        }
    }

    Sys.Application.add_navigate(function (sender, e) {
        var state = e.get_state();

        // Валидируем значения, т.к. они получены из Query String и могут быть потенциально небезопасны
        var view = parseInt(state.view);
        var filter = parseInt(state.filter);
        var prefs = parseInt(state.prefs);

        if (isNaN(view) || isNaN(filter) || isNaN(prefs))
            return;

        DW.TasksDashboard.ViewManager.RestorePreviouslySavedView(state);
    });

    function onDataLoaded() {
        Sys.Application.addHistoryPoint({
            view: DW.TasksDashboard.ViewManager.get_CurrentViewFlags(),
            filter: DW.TasksDashboard.ViewManager.get_CurrentFilterFlags(),
            prefs: DW.TasksDashboard.ViewManager.get_CurrentAdditionalFlags()
        });
    }

}

DW.TasksDashboard.UniqueURLs = new DW.TasksDashboard._UniqueURLs();
_spBodyOnLoadFunctionNames.push("DW.TasksDashboard.UniqueURLs.FixOnFlyLocalization");

Он зависит от некоторых других классов моего проекта, но я надеюсь, он очень хорошо демонстрирует концепцию паттерна UniqueURLs, и заодно, этот пример должен вам помочь правильно изолировать логику UniqueURLs от всего остального решения. Мне кажется, здесь эта логика изолирована очень удачно.

В итоге, адресная строка моего дашбоарда выглядит примерно так:

, т.е. параметры в строке состояния полностью соответствуют положению переключателей в трех разных группах на контекстной ленте (Views, Filters и Preferences). И если мы начинаем переключать кнопки на ленте, эти переключения тут же отражаются в адресной строке.

Мне кажется, это очень классно и очень удобно. Решается как минимум одна бизнес-задача: например, если клиент вдруг захочет, чтобы для всех пользователей дашбоард открывался по умолчанию на фильтре “Задачи, назначенные на меня моим руководителем”, или на какой-то другой особой комбинации настроек/фильтров/представлений, то он сможет просто отредактировать ссылку в главном меню – и вуаля, проблема решена.

Подводя итог: очень рекомендую обратить внимание на Ajax-паттерны и использовать их, если они подходят вашему решению – часто эти паттерны требуют совершенно пустяковых затрат в реализации, но зато могут значительно повысить удобство ваших интерфейсов, особенно если вы реализуете не один, а хотя бы 2-3 паттерна. Список Ajax-паттернов можно найти на сайте AjaxPatterns.org.

PowerShell-скрипт для генерации задач

2012-05-29T09:20:00.000+04:00

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

$random = New-Object System.Random

function RandomDay()
{
    $start = New-Object System.DateTime(1995, 1, 1);

    $range = ([System.TimeSpan]([System.DateTime]::Today - $start)).Days;           
    return [System.DateTime]$start.AddDays($random.Next($range));
}

, вернет случайную дату. Полученные с её помощью значения можно использовать для заполнения колонок “Start Date” и “Due Date”.

Функции по генерации приоритета, статуса и прогресса задачи также довольно простые:

function RandomPriority()
{
    $priorities = "(1) High","(2) Normal","(2) Normal","(2) Normal","(3) Low"
    return [System.String]$priorities[$random.Next(0,5)]
}
function RandomStatus()
{
    $status = "Completed","Deferred","In Progress","Not Started"
    return [System.String]$status[$random.Next(0,4)]
}
function RandomProgress()
{
    $r = ($random.Next(0,20) * 5);
    if ($r -lt 10)
    {
       return [System.String]"0.0" + $r
    }
    else
    {
       return [System.String]"0." + $r
    }
}

Более интересна функция по генерации заголовка задачи. Она определяет список действий и список контрагентов (названия контрагентов взяты из базы NorthWind), берет по одному значению из каждого списка, и склеивает их в единую строку. Вот так:

function RandomTitle()
{
    $agents = "Alfreds Futterkiste","Ana Trujillo Emparedados y helados","Antonio Moreno Taqueria","Around the Horn","Berglunds snabbkop",
        "Blauer See Delikatessen","Blondesddsl pere et fils","Bolido Comidas preparadas","Bon app","Bottom-Dollar Markets",
        "B's Beverages","Cactus Comidas para llevar","Centro comercial Moctezuma","Chop-suey Chinese","Comercio Mineiro",
        "Consolidated Holdings","Drachenblut Delikatessen","Du monde entier","Eastern Connection","Ernst Handel",
        "Familia Arquibaldo","FISSA Fabrica Inter. Salchichas S.A.","Folies gourmandes","Folk och fa HB","Frankenversand",
        "France restauration","Franchi S.p.A.","Furia Bacalhau e Frutos do Mar","Galeria del gastronomo","Godos Cocina Tipica",
        "Gourmet Lanchonetes","Great Lakes Food Market","Hanari Carnes","GROSELLA-Restaurante","HILARION-Abastos"
    $actions = "Arrange a meeting with ","Demonstrate the product to ","Call ","Meet ","Discuss possibilities with ",
        "Sign contract with ", "Implement request from ", "Prepare materials for ", "Prepare documents for ", "Accord document with ",
        "Prepare advertisement for "
    return [System.String]$actions[$random.Next(0,12)] + $agents[$random.Next(0,35)]
}

Наконец, нужно определить функцию, которая генерит XML для массового добавления записей через ProcessBatchData:

function Generate50Tasks($listID)
{
  $method = "<Method ID=""{0}""><SetList>" + $listID + "</SetList>`n";
  $method += "<SetVar Name=""Cmd"">Save</SetVar>`n<SetVar Name=""ID"">New</SetVar>`n";
  $method += "<SetVar Name=""urn:schemas-microsoft-com:office:office#Title"">{1}</SetVar>`n"
  $method += "<SetVar Name=""urn:schemas-microsoft-com:office:office#StartDate"">{2}</SetVar>`n"
  $method += "<SetVar Name=""urn:schemas-microsoft-com:office:office#DueDate"">{3}</SetVar>`n"
  $method += "<SetVar Name=""urn:schemas-microsoft-com:office:office#Priority"">{4}</SetVar>`n"
  $method += "<SetVar Name=""urn:schemas-microsoft-com:office:office#Status"">{5}</SetVar>`n"
  $method += "<SetVar Name=""urn:schemas-microsoft-com:office:office#PercentComplete"">{6}</SetVar>`n"
  $method += "</Method>`n"
  $methods = ""
  for($i = 1;$i -le 50; $i++)
  {
    $title = RandomTitle
    $startDate = RandomDay
    $dueDate = RandomDay
    $priority = RandomPriority
    $status = RandomStatus
    $percentComplete = RandomProgress
    $methods = $methods + [System.String]::Format($method, $i, $title, $startDate.ToString("s"), $dueDate.ToString("s"), $priority, $status, $percentComplete.ToString().Replace(",","."))
  }
  return [System.String]::Format("<?xml version=""1.0"" encoding=""UTF-8""?><ows:Batch OnError=""Return"">{0}</ows:Batch>", $methods);
}

Генерация 50 записей обеспечивает относительную уникальность заголовков. Конечно, можно генерировать и по 150 записей, и нагенерить несколько тысяч задач, – но это требуется не так часто.

Давайте, наконец, сгенерируем записи:

$web = Get-SPWeb http://localhost
$list = $web.Lists["Tasks"]
$xml = Generate50Tasks $list.ID
$web.ProcessBatchData($xml)

Здесь исправьте хост/порт и заголовок списка на тот, который соответствует вашему порталу.

Также, вы можете скачать скрипт в виде файла. Если у вас русский портал, у меня есть и русская версия скрипта.

После генерации, получите примерно такую картинку:

Если использовать русский скрипт, картинка будет немного другой:

Русскоязычные SharePoint-блоггеры

2012-05-28T09:15:00.000+04:00

К сожалению, людей, хорошо пишущих про SharePoint на русском языке — единицы. Под «хорошо» я имею в виду уникальный, интересный контент, грамотно оформленный и представляющий практическую ценность. Впрочем, несколько человек всё-таки есть, и сегодня мне хочется о них рассказать и обратить на них внимание общественности, потому что, к сожалению, нередко эти блоги далеко не настолько популярны, насколько они этого заслуживают (возможно, причина в том, что многие SharePoint-разработчики свои запросы в гугле набирают исключительно по-английски?...).

Итак, поехали...

Стас Выщепан

Стас — наверное один из самых знающих людей по SharePoint, причем не только среди русскоязычных экспертов. В 2011м году он был совершенно заслуженно награжден статусом SharePoint MVP, также он имеет статус MCT (Microsoft Certified Trainer) и большой опыт работы в роли тренера. Он знает намного больше меня во многих областях, и проповедует несколько очень интересных техник разработки под SharePoint. С ним всегда очень интересно общаться, его доклады — интересно слушать, и также он пишет очень подробные и понятные статьи.

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

Особенно я хочу отметить две серии статей из блога Стаса, про простое в глубину:

Про Event Receiver’ы (есть и вторая часть)
Про Timer Job’ы

У него в блоге, конечно же, есть и множество других крайне полезных статей, и если вы еще не подписаны на него или не читали — давно пора исправить это недоразумение! :)

Игорь Акимов

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

Например, один из последних его постов рассказывает о малоизвестном и, как водится, недокументированном ActiveX-контроле, который в SharePoint используется для массовой загрузки файлов на сервер.

Другой пост Игоря повествует о том, что оказывается страницы веб-частей можно развертывать с помощью метода ProcessBatchData. К слову, этот метод вообще очень интересный, и помимо развертывания веб-частей и наиболее известных операций по массовому добавлению/изменению элементов списка умеет еще много чего (о чем почти никто не знает). В блоге у Stefan Stanev (англоязычном) можно найти несколько других вкусностей о ProcessBatchData.

Виталий Жуков

Виталий Жуков впервые привлек мое внимание серией статей по обзору DeskWork :), в создании которого я принимаю участие в течение последних более чем 2х лет работы в Softline. И лишь позже я обнаружил, что у него в блоге много и других интересных постов, и посты эти появляются просто-таки стремительно :)

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

У Виталия есть и другие статьи. Например, меня очень заинтересовала статья про ListTitleViewSelectorMenu. Проблема очень распространенная: если на страницу представления списка подложить веб-часть фильтрации, то из заголовка страницы тут же исчезает меню выбора текущего представления. К сожалению, в статье мало подробностей и нет исходного кода, но суть решения понятна, и в некоторых случаях, мне кажется, такое решение вполне имеет право на жизнь.

Другая понравившаяся статья — про то, как запретить выбирать отключенных в AD пользователей в PeoplePicker.

Alejo El Norte

Блог Alejo El Norte был создан совсем недавно, но уже сейчас даже опытные SharePoint-эксперты могут с удивлением обнаружить там некоторые очень полезные штуковины, о которых они не знали :) На текущий момент, наиболее интересными для меня постами являются посты про Download.aspx, CopyUtil.aspx, и клиентскую функцию GoToPage. Ни одной из этих фишек я на момент прочтения не знал. Если так будет продолжаться и дальше, у этого блога — большое будущее :)

Другие блоги

Хочется также упомянуть блоги Антона Вишнякова и Игоря Афанасова. Эти блоги на текущий момент не очень активны, но в любом случае, авторы успели написать немало интересных постов, которые стоит почитать.

У Игоря Афанасова — немало заметок о книгах по SharePoint. Также мне очень понравилась последняя заметка из его блога: Полезные протоколы SharePoint.

Антон Вишняков много писал про InfoPath. Также, в его блоге можно найти несколько забавных ошибок в SharePoint, и несколько очень правильных «no code» решений.

Заключение

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

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

Генерация JS из C# с помощью T4

2012-05-27T15:11:00.001+04:00

В Ajax-приложениях данные передаются между клиентской и серверной стороной. Естественно, что структуру этих данных необходимо знать и на клиенте, и на сервере. Обычно это означает ведение одних и тех же классов, интерфейсов и перечислений и в виде JS-файлов, и в виде C#-файлов. Это лишняя работа, неудобно и вообще опасно.

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

Чтобы избавиться от такого рода ошибок и от лишней работы, я использую T4-преобразования, и генерирую JS-файлы на основе C#. В этой статье я расскажу, как такие преобразования устроены и работают. В конце статьи выложен код итогового T4-преобразования, которое можно скачать и использовать в ваших собственных проектах без изменений. Итак, поехали!

Code Model

Code Model – это функциональность, предоставляемая Visual Studio, позволяющая просматривать (и даже изменять) описания классов, методов, свойств и полей во всем вашем проекте. Похоже на Reflection, но намного удобнее. Подробнее о Code Model можно прочитать на MSDN.

Замечание: Code Model работает только в среде Visual Studio, поэтому использующие этот функционал T4-преобразования нельзя запускать за пределами VS, например в Continious Integration-билдах.

Code Model позволяет перебирать все элементы кода, и у каждого из этих элементов есть коллекция Children, которую тоже можно перебрать, и т.д.
Простейший пример использования Code Model выглядит примерно так:

foreach (EnvDTE.CodeElement element in projectItem.FileCodeModel.CodeElements)
{
    if (element.Kind == EnvDTE.vsCMElement.vsCMElementNamespace)
    {
        foreach (EnvDTE.CodeElement innerElement in element.Children)
        {
            switch (innerElement.Kind)
            {
                case EnvDTE.vsCMElement.vsCMElementClass:
                    Debug.WriteLine("Class: " + innerElement.Name);
                    break;
                case EnvDTE.vsCMElement.vsCMElementEnum:
                    Debug.WriteLine("Enum: " + innerElement.Name);
                    break;
                case EnvDTE.vsCMElement.vsCMElementInterface:
                    Debug.WriteLine("Interface: " + innerElement.Name);
                    break;
            }
        }
    }
}

Соответственно, если взглянуть дальше вглубь классов/перечислений/интерфейсов, сгенерировать их описания для JavaScript довольно легко.

Кстати, очень хороший пример с генерацией SQL-таблиц на основе C#-перечислений с использованием T4 и Code Model можно найти у Олега Сыча. У Олега в блоге вообще очень много про T4, рекомендую почитать.

ООП и ASP.Net Ajax

Для реализации ООП в JavaScript я использую в своих проектах библиотеку ASP.Net Ajax. К слову, эта библиотека (версии 3.5) уже присутствует в составе SharePoint, так что SharePoint-разработчикам ничего дополнительно подключать не потребуется.

Как известно, JavaScript не является объектно-ориентированным языком, поэтому ООП-объекты JavaScript выглядят порой довольно неказисто. Например, чтобы объявить перечисление в ASP.Net Ajax, при этом используя inline-документацию, нужно написать довольно много кода. Реальный пример из рабочего проекта:

DW.TasksDashboard.DashboardFilter = function() {
    /// <summary>Предустановленные фильтры для Центра задач</summary>
    /// <field name='AllTasks' type='Number' integer='true' static='true'>Все задачи (без фильтрации)</field>
    /// <field name='TasksAssignedToMe' type='Number' integer='true' static='true'>Задачи, назначенные на текущего пользователя</field>
    /// <field name='TasksCreatedByMe' type='Number' integer='true' static='true'>Задачи, созданные текущим пользователем</field>
    /// <field name='ManagerTasks' type='Number' integer='true' static='true'>Задачи, созданные руководителем текущего пользователя и назначенные на текущего пользователя</field>
    /// <field name='DepartmentTasks' type='Number' integer='true' static='true'>Задачи, назначенные на членов отдела текущего пользователя (включая его самого)</field>
    /// <field name='DeputyTasks' type='Number' integer='true' static='true'>Задачи, назначенные на пользователей, которых замещает текущий пользователь</field>
    /// <field name='SecretaryTasks' type='Number' integer='true' static='true'>Задачи, назначенные на пользователей, для которых текущий пользователь - секретарь</field>}

DW.TasksDashboard.DashboardFilter.prototype = {
    AllTasks: 1,
    TasksAssignedToMe: 2,
    TasksCreatedByMe: 3,
    ManagerTasks: 4,
    DepartmentTasks: 5,
    DeputyTasks: 6,
    SecretaryTasks: 7
}
DW.TasksDashboard.DashboardFilter.registerEnum('DW.TasksDashboard.DashboardFilter');

Как описывать другие ООП-объекты с помощью ASP.Net Ajax (классы, интерфейсы, события и т.д.), вы можете найти в документации по этой библиотеке, например в статье Extending JavaScript with ASP.NET AJAX. Имея это знание, написать итоговый код несложно. Взамен, вы можете использовать t4-файл, который написал я. Просто добавьте его в проект, и измените пути к файлам, которые необходимо обрабатывать.

Заключение

Принцип DRY (Do not repeat yourself) – это один из основополагающих принципов в программировании. Его соблюдение дает множество преимуществ. И даже если без повторения одного и того же кода не обойтись, как это имеет место быть в случае Ajax-приложений с общей моделью данных, T4-шаблоны могут помочь в этой ситуации, и сгенерировать нужный код автоматически.

К слову, генерация JS-кода на основе C# также является паттерном, одним из т.н. Ajax-паттернов, т.е. специально заточенных под Ajax-приложения. Этот паттерн называется Server-Side Code Generation.

Другим способом генерации JS на основе C#, более общим, является использование Script# – этот проект позволяет компилировать С#-код в JavaScript, и активно используется даже во внутренней разработке в компании Microsoft. В частности, судя по всему, SharePoint Client Object Model тоже написан на Script#.

Разработка больших JavaScript-решений: 1 файл = 1 класс

2012-05-25T21:11:00.001+04:00

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

1 класс = 1 файл
В 1 файле – не более 300 строк

Эти правила отлично работают и для серверного кода, и для клиентского. Но если серверный код автоматически, средствами Visual Studio, компилируется в единственный dll-файл, то JavaScript приходится склеивать в один кусок “вручную”.

В этом посте я хочу рассказать, как это можно сделать.

А сделать это можно разными способами... Например, это можно сделать с помощью свойства CompositeScript объекта ScriptManager. Но ScriptManager частично не работает в SharePoint Sandbox, и к тому же этот вариант не позволяет произвести минификацию итогового JavaScript.

Поэтому я использую для склейки примитивное T4-преобразование. Например, давайте предположим, что в корневой папке проекта у вас лежат файлы Script1.js и Script2.js:

Чтобы их склеить, T4-шаблон будет следующим:

<#@ template debug="false" hostspecific="true" language="C#" #>
<#@ output extension=".js" #>
<#@ Import Namespace="System.IO" #>

Type.registerNamespace("MyCompany.MyNamespace");

<#= GetFileContents(@"Script1.js") #>
<#= GetFileContents(@"Script2.js") #>

<#+

    private string GetFileContents(string filename)
    {
        var path = Path.GetDirectoryName(this.Host.TemplateFile);
        return File.ReadAllText(Path.Combine(path, filename));
    }

#>

Этот код нужно добавить в файл типа “Text Template”:

Как только вы скопипастите код в файл и сохраните его, в подчиненном js-файле обнаружится склеенное содержимое Script1.js и Script2.js:

Что ж, файлы склеили – получили “debug”-версию скрипта. Но для отгрузки на продакшн использовать такую склейку, конечно, не годится – надо бы её минифицировать. Это можно сделать очень легко с помощью утилиты Microsoft Ajax Minifier, доступной на Codeplex.

После установки Ajax Minifier, вам потребуется прописать строку его вызова в Pre-Built Event проекта. Для нашего случая строка будет выглядеть примерно так:

"C:\Program Files (x86)\Microsoft\Microsoft Ajax Minifier\AjaxMin.exe" -JS $(ProjectDir)\CompositeScript.debug.js -out $(ProjectDir)\CompositeScript.js -CLOBBER

(опция -CLOBBER позволяет Minifier’у перезаписывать файлы).

После первого билда можно включить сгенерированный файл CompositeScript.js в состав проекта.

Таким образом, получаем две версии полного JavaScript-файла. Впоследствии обе версии можно каким-нибудь способом задеплоить в SharePoint. Контрол ScriptLink автоматически будет подключать debug- или release-версию скрипта в зависимости от текущей настройки параметра debug в файле web.config.

P.S. Также о минификации можно почитать у Wictor Wilen.

Впечатления от MsDevCon’12 и пара интересностей о SharePoint

2012-05-25T15:19:00.001+04:00

Вернулся с конференции MsDevCon, море впечатлений и эмоций, спешу поделиться!

Я на конференции

Напомню, я участвовал в конференции как докладчик, читал доклад “Разработка Ajax-приложений в SharePoint”. Видео докладов организаторы планируют выложить не раньше чем через неделю, так что если кто-то пропустил, придется ждать :(

В любом случае, как я и обещал на докладе, я уже опубликовал два сопутствующих поста к докладу:

Место проведения – "Яхонты"

Качество сервиса было на самом деле просто шикарным. Организация тоже в принципе на высоте (единственный наверное недочет, это то что зона экспертов никак не была обозначена – ни на плане, ни указателями, ни вывеской). Ощущение, что съездил не просто на конференцию, но съездил отдохнуть в отпуск, и вдобавок еще и на очень классную конференцию попал :) Природа, свежий воздух, кормежка “на убой”, шикарные условия размещения. Причем, это впечатление не могла испортить даже довольно прохладная погода. И кстати, несмотря на то, что кто-то боялся комаров, комаров было на самом деле не так много, и они были не слишком навязчивыми.

Отдельно про официантов: официанты были просто бесподобны! :) Представьте себе гризли-подобного мужика, с руками толщиной в две обычных, и ростом под два метра. А теперь представьте его одетым в ливрею официанта :) Это было очень забавно! :)

Хансельман

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

Хансельман (Scott Hanselman) – это один из самых выдающихся IT-докладчиков на сегодняшний день. Если вы еще не смотрели ВСЕ его доклады, очень рекомендую! Даже если вы не узнаете ничего нового (что невероятно, потому что Скотт очень любит собирать маленькие фишки о которых никто не знает), всегда стоит посмотреть Хансельмана. Это человек-театр, это зрелище которое просто нельзя пропускать.

Более того, нам удалось пообщаться со Скоттом вживую (!!). На фотографии Стас Выщепан, я и Скотт:

Очень общительный человек, Скотт бродил среди участников и среди экспертов в перерывах между докладами, и с удовольствием вступал в любые дискуссии и отвечал на любые вопросы. Всегда старался помочь, в частности мне удалось обратить его внимание на проблему со Script# в SharePoint.

Наверное хотя бы некоторые из вас знают, что SharePoint Client Object Model написан на Script#? Возможно, кто-то из вас также пробовал писать на Script# самостоятельно, и знают, чего это стоит, написать wrapper для какой-нибудь более-менее серьезной библиотеки? Возникает естественный вопрос, а что мешает Microsoft’у частично открыть исходники SharePoint ClientOM (для создания wrapper’а Script# не требуется реализация, только определения методов/классов/свойств и т.д.), сделав тех, кому нравится Script#, ну ОЧЕНЬ счастливыми? :)

Такой вопрос мы задали Скотту, и после того как он понял проблему, он тут же написал создателю Script#, которого зовут Nikhil Kothari. Я искренне надеюсь, что у этого обращения будут какие-то результаты, потому что те, кто хоть раз использовал Script# – знают, насколько это классный инструмент, и насколько проще с его помощью писать серьезные JavaScript-приложения.

Также, мы говорили со Скоттом о KnockOut. У меня есть некоторый опыт практической работы с KnockOut.js в SharePoint, и недавно я даже делал в Softline внутренний доклад “KnockOutJs в SharePoint”. На докладе я озвучивал проблему с атрибутом data-bind, с которой столкнулся самолично. Этот атрибут, как известно, очень хитрый. Он может содержать простые биндинги, а может целые выражения. Сделать ошибку в этом атрибуте ничего не мешает: значение атрибута является не более чем строкой, и сообщения об ошибках далеко не всегда внятные. Более того, поскольку биндингов очень много разных, и далеко не все из них сразу срабатывают, то мы можем вообще не получить никакого сообщения об ошибке и ошибочный вариант может запросто уйти на продакшен. А когда ошибка просачивается к клиентам, это уж совсем ужасно…

Ответ Скотта состоял из двух пунктов:

Microsoft не собирается делать интеллисенс или пре-компилятор для KnockOutJs или для других OpenSource-проектов, даже несмотря на то, что сейчас KnockOutJs поставляется вместе с ASP.Net MVC 4. Причина проста: это очень дорого и это очень сложно. В этом я со Скоттом полностью согласен: в свое время я писал интеллисенс для LUA, и сложилось впечатление, что это даже сложнее, чем написать с нуля компилятор LUA…
Как вариант решения проблемы, Скотт предложил написать расширение для Visual Studio, которое бы добавляло подсветку внутрь аттрибута data-bind. Причем он показал, что подобные расширения действительно можно написать, в качестве примера приведя Colorizer для Mustache Templating Engine, который был написан вроде как всего за одну ночь создателем этого движка, человеком по имени Mads Kristensen. Более подробно об этом можно почитать у Скотта в блоге. Подсветка Mustache-кода (с помощью vsix-расширения) выглядит вот так (картинка заимствована из блога Скотта):

По-моему, решение весьма достойное (как минимум, “it sucks less”, как говорит Скотт :)…), и по наличии времени, я обязательно попробую разобраться, как это делается. Все-таки, в некоторых разрезах, KnockOutJs сделан очень удачно, и существует много ситуаций, когда его применение значительно облегчает жизнь разработчику.

На этом, пожалуй, всё, всем желаю удачных надвигающихся выходных, и да.. MsDevCon’12 был супер!

HTML5 и SharePoint

2012-04-10T20:46:00.001+04:00

Провожу серию докладов в своем отделе. Чтобы определить самые интересные для коллег темы докладов, мы провели анонимное голосование:

Результаты оказались довольно неожиданными для меня: со значительным отрывом победила тема "Общие сведения по HTML5 и CSS3". В сочетании с другими предлагавшимися темами, получилось, что 34% всех голосов были за HTML5.

Поэтому, первым докладом в серии стал доклад "SharePoint и HTML5". Значительная часть доклада посвящена общему описанию: что такое HTML5, почему он вдруг потребовался, и какие основные возможности включает.

Также, чтобы увеличить ценность доклада, при описании возможностей HTML5 я рассказываю о своем реальном опыте применения этих возможностей, и особенно об опыте применения HTML5 в SharePoint.

Не смею больше томить, вот собственно доклад:

Scrum в команде SharePoint

2012-02-15T09:30:00.000+04:00

Вчера завершился очередной спринт. По результатам: почти все задачи выполнены, большая часть из выполненных уже протестирована и закрыта, и ребята даже успели позаниматься парным программированием... :)

На самом деле, вот еще буквально полгода назад я думал что Scrum в команде, которая делает SharePoint, не очень актуален. Я считал, что из-за особенностей разработки под SharePoint, из-за того что мы фактически пишем кучу слабосвязанных плагинов, а не цельный продукт - командная разработка привносит больше вреда, чем пользы: это происходит из-за оверхеда на общение и организационные процедуры, которые вроде как никому особо и не нужны, т.к. каждый занят своим модулем и в чужие дела не лезет.

Как вы уже наверное догадались, я ошибался. Причем, сильно ошибался...

Итак, что же дает Scrum, что дает командная разработка и почему это применимо к SharePoint?

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

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

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

Ну и конечно, деловое общение на разнообразных Scrum-собраниях - это обмен опытом, обмен идеями (brainstorming), активное отслеживание рисков и проблем, взаимопомощь. Всё это сильно повышает эффективность и очень быстро окупается.

С точки же зрения бизнеса, Scrum прежде всего дает предсказуемость. Реально работающую оценку трудозатрат, которая подтверждается из спринта в спринт. Вспомните, ведь любой проект начинается с вопроса: "За сколько ты сможешь это сделать?". И правильная оценка - безусловный залог стабильной прибыли и довольных клиентов.

Кстати, кто работал с оценками по SharePoint-проектам, те знают и понимают, что хороший estimation в SharePoint - это очень сложно. Влезли в стандартный функционал - задача решается за полдня. Не влезли - попали на месяц трудозатрат. И тем не менее, planning poker из спринта в спринт срабатывает, и это даже для SharePoint, и это даже несмотря на то, что наш Scrum на самом деле весьма далек от идеального Scrum'а. Как? Точно не знаю. Но работает :)

В общем, на самом деле я лично очень доволен, и надеюсь наш отдел будет продолжать развиваться в том же духе :)

Генерация большого числа записей в список SharePoint

2012-02-08T21:49:00.001+04:00

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

Поэтому неплохо это уметь, а не уповать "на авось", тем более что делается это очень просто с помощью довольно короткого PowerShell-скрипта. У меня давно уже валяется такой скрипт, который использую лично я, вот решил поделиться :)

Не смею больше тянуть:

# Генерим XML для создания 150 записей в списке с GUID = $listID
# Колонку с InternalName=$column заполняем случайными числами от 1 до 10 млн.
function Generate150Items($listID, $column)
{
  $method = "<Method ID=""{0}""><SetList>" + $listID + "</SetList><SetVar Name=""Cmd"">Save</SetVar><SetVar Name=""ID"">New</SetVar><SetVar Name=""urn:schemas-microsoft-com:office:office#" + $column + """>{1}</SetVar></Method>`n"
  Write-Host Method template: $method
  $methods = ""
  $r = New-Object System.Random
  for($i = 1;$i -le 150; $i++)
  {
    $methods = $methods + [System.String]::Format($method, $i, $r.Next(1,10000000))
  }
  return [System.String]::Format("<?xml version=""1.0"" encoding=""UTF-8""?><ows:Batch OnError=""Return"">{0}</ows:Batch>", $methods);
  
}

# Пример использования
$web = Get-SPWeb http://localhost
$list = $web.Lists["Your list title"]
$xml = Generate150Items $list.ID "Title"
$results = $web.ProcessBatchData($xml)

Результат:

В списке:

P.S.: Да, желательно тестовые данные создавать в тестовых списках, потому что удалить, к примеру, 15000 записей без удаления самого списка - на самом деле далеко не так просто, как это может показаться :)

Но если вам все-таки нужно будет удалить много записей, и не удалять при этом список - как это сделать правильно, описано на SharePoint StackExchange (к слову, это ответ многим известного Игоря Афанасова).

Введение в рабочие процессы SharePoint 2010

2011-11-08T08:03:00.000+04:00

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

Я считаю, что без понимания концепции рабочих процессов и их возможностей, - ваше знание SharePoint'а нельзя считать полным! И на мой взгляд, их действительно стоит изучать: они классные, и могут вам сэкономить немало дней, если их использовать с умом и по-назначению.

Впрочем, как это всегда бывает в SharePoint, существует множество тонкостей, нюансов и особенностей, которые нужно знать и иметь в виду, прежде чем говорить клиенту/начальнику о том, что вот мол на решение этой задачи уйдет полдня :)

Итак, давайте рассмотрим вкратце, что представляют собой рабочие процессы в SharePoint. Эта статья является стартовой в новой серии статей про рабочие процессы.

Практическое применение

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

С точки зрения программистов, рабочие процессы могут поначалу очень напоминать Event Receiver. Поэтому важно понимать - на самом деле они гораздо сложнее, чем Event Receiver, устроены совершенно иначе, и подразумевают, прежде всего:

Возможность длительного исполнения
Возможность дополнительного взаимодействия с пользователями

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

Наконец, практический пример использования рабочих процессов: в компании Softline, где я работаю, у нас есть огромный внутрикорпоративный портал на SharePoint, где на основе Workflow работают, как минимум: заявки, системы единого окна и система разрешения внутренних проблем HelpDesk. Не раз пользовался - весьма удобно. А ведь этот портал создан администраторами, т.е. с минимумом программирования или вообще без него! И я видел специализированные системы - поверьте, некоторые и похуже с такими задачами справляются...

Когда стоит, и когда не стоит использовать рабочие процессы?

Ответ на самом деле очень прост, и частично содержится в самом вопросе: если речь идет о бизнес-требованиях и моделировании бизнес-процессов - нужно использовать Workflow. Для более низкоуровневого функционала, с бизнесом непосредственно не связанного - лучше подойдут Event Receivers и Timer Jobs.

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

Три типа рабочих процессов SharePoint 2010

Рабочие процессы в SharePoint 2010 значительно обновились по сравнению с 2007 версией, и на текущий момент могут быть трех типов: Site Workflow, Reusable Workflow и List Workflow. Как нетрудно догадаться, эти типы отличаются друг от друга объектами, в контексте которых работает рабочий процесс.

Первый тип - Site Workflows - пригождается довольно редко, и рассматривать его в сегодняшнем посте я не буду. List Workflows мы тоже рассматривать не будем, это устаревший тип, пришедший из 2007го SharePoint'а. Вкратце, рабочие процессы этого вида присоединяются обязательно к уже созданному экземпляру списка. Таким образом, применение этих рабочих процессов очень ограничено, они не могут быть перенесены или использованы повторно и т.д.

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

Поскольку типы содержимого могут наследоваться друг от друга, можно выбрать базовый тип содержимого "All" - в этом случае ваш рабочий процесс можно будет использовать вообще в любом списке, но тогда он сможет оперировать только самыми простейшими колонками - Title, Created, Created By, Modified, Modified By...

Впрочем, здесь есть важное уточнение: существуют так называемые Association Columns - это колонки, которые будут автоматически созданы в списке при присоединенни к нему Reusable-рабочего процесса. Но тут, опять же, важно понимать: эти колонки будут созданы в любом случае, даже если аналогичные колонки с теми же именами уже в этом списке существуют.

Три инструмента для создания рабочих процессов

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

Microsoft Visio
SharePoint Designer
Visual Studio

При этом Microsoft Visio позволяет только нарисовать красивый "набросок" рабочего процесса, который потом нужно обязательно изменять в SharePoint Designer. Впрочем, для бизнес-пользователей такой вариант очень хорош: они могут нарисовать процесс не вдаваясь в детали, а дорабатывать его будет уже администратор, программист или IT-специалист.

Плюс к тому, с помощью Visio, рабочие процессы могут быть визуализированы через веб-интерфейс. Это очень классная "фишка", которая позволяет отобразить диаграмму процесса на сайте SharePoint, причем уже выполненные шаги будут помечены галочками. На мой взгляд, это может служить прекрасным добавлением к каким-нибудь отчетам/dashboard'ам. Функция работает только в SharePoint Server 2010, при наличии запущенных Visio Services, и включенной галочке в свойствах рабочего процесса в SPD:

В общем, Visio скорее нужно рассматривать как некое приятное дополнение к SharePoint Designer, чем как самостоятельный инструмент для создания SharePoint Workflow.

Так что давайте рассмотрим следующий инструмент - собственно SharePoint Designer. Его можно использовать и без Visio, он вполне самодостаточен. Вообще, на мой взгляд, SPD как средство для создания рабочих процессов - это лучший вариант, потому что:

Визуальный редактор в SPD - очень приятный и интуитивно-понятный. К слову, намного лучше, чем был в SPD 2007.
SPD-workflow - это единственный тип workflow, который работает в Sandbox и Office365
Reusable workflows можно переносить между фермами и сайтами
Можно разрабатывать программные расширения (собственные Actions) для SPD-редактора. Эти расширения развертываются на сайт, и потом SharePoint Designer при подгрузке списка Workflow с сайта заодно подгружает и расширения, сразу же соответствующим образом обновляя свой интерфейс. Эта фишка работает в том числе и для Sandboxed Solutions.

Внешний вид дизайнера рабочих процессов SPD 2010

Наконец, последний вариант, Visual Studio Workflows. Минусы:

Функционально больших отличий от SPD нет. Конечно, у SPD-workflows есть ряд ограничений, но на практике, все они обходятся через использование программных расширений, дополнительных колонок, или дополнительных workflow.
Если попробовать реализовать один и тот же функционал средствами Visual Studio и средствами SPD - в Visual Studio это делается значительно дольше и сложнее.
SharePoint Workflows в Visual Studio реализованы на основе Windows Workflow Foundation, которая сама по себе весьма глючная - а SharePoint туда еще добавляет немало "нюансов" :)
Visual Studio Workflows даже теоретически не работают в Sandbox. В свете выхода Office365, мне кажется это очень актуально.

Конечно, Visual Studio гораздо более гибкий и всё такое, но такая низкоуровневая гибкость на практике пригождается редко, а вот разработку и поддержку значительно усложняет.

Поэтому я стараюсь использовать SPD Workflows и писать для них Sandboxed Workflow Actions.

Заключение

Надеюсь, этот краткий обзор помог обратить ваше внимание на рабочие процессы SharePoint 2010 и обозначил некоторые общие направления для дальнейшего изучения. Конечно, полностью описать систему в рамках статьи невозможно: рабочие процессы - это действительно мощная система, и понадобилась бы целая книга, чтобы подробно её описать. Кстати, такая книга уже есть, её написал Phil Wicklund, рекомендую: SharePoint 2010 Workflows In Action (на английском языке).

В следующих постах серии мы рассмотрим создание Sandboxed Workflow Actions, примеры "боевых" рабочих процессов, способы обхода встроенных ограничений рабочих процессов SPD, и многое другое. Так что, если еще не подписались на RSS - уже пора! :)

SharePoint и XSLT: преобразуем колонку в строку

2011-10-26T09:00:00.000+04:00

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

Но как видите, всё равно в строке с комментарием остается много пустого места:

Сегодня давайте попробуем расширить пример, вынеся комментарий вообще в отдельную строку, получив в финале примерно такой вид:

Вперед?

Прежде всего, давайте вспомним теорию и упрощенное дерево шаблонов XsltListViewWebPart:

В предыдущем примере мы изменяли шаблон PrintTableCellEcbAllowed у заголовочной ячейки, и помещали туда дополнительный div, в который вставляли текст комментария руководителя. Легко догадаться, что в этот раз шаблон PrintTableCellEcbAllowed нам не поможет: придется подниматься по дереву шаблонов вверх, и работать уже с шаблоном Item, который, напомню, выводит элемент <tr> - то есть всю строку.

Нам нужно всего лишь научить этот шаблон в некоторых случаях (когда PM's comment не пустой) выводить два элемента <tr> вместо одного, и во второй <tr> вставлять тот же самый <div>.

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

Получить код стандартного шаблона Item.
Найти в этом коде завершающий тег </tr>, и после него добавить условный вывод еще одного <tr>, содержащего уже известный нам по посту про объединение двух колонок <div>.

Получить код стандартного шаблона Item можно двумя способами.

Во-первых, можно открыть в браузере на SharePoint-портале файл /_layouts/xsl/vwstyles.xsl, и найти там шаблон <xsl:template mode="Item"

Во-вторых, можно воспользоваться старым трюком с Conditional formatting, выбрав форматирование строки (а не столбца, как мы выбирали в прошлый раз):

Далее нужно выбрать любое невыполнимое условие (например ID='0'), и подключить любой стиль.

В конечном итоге, всё равно получим в нашем теге <Xsl> шаблон Item. Пролистываем до конца этого шаблона, видим закрывающий тег </tr>. Ага, он-то нам и нужен!

После него и перед </xsl:template>, нужно добавить следующий код:

    <xsl:if test="$thisNode/@PM_x0027_s_x0020_comment != ''">
      <tr>
        <td colspan="{count($Fields)+1}">
          <div style="background-color:#FFEEEE; margin: 5px; padding: 4px 10px; font-size: 9px;">
            <xsl:apply-templates select="../FieldRef[@Name='PM_x0027_s_x0020_comment']" mode="PrintFieldWithECB">
              <xsl:with-param name="thisNode" select="$thisNode"/>
            </xsl:apply-templates>
          </div>
        </td>
      </tr>
    </xsl:if>

На самом деле, я скопировал этот код из предыдущей статьи. Всё что я сделал здесь - это обернул <div> в <tr> и <td>, причем в <td> указал атрибут colspan, чтобы расширить ячейку на всю строку.

Переменная $Fields - это список всех полей (FieldRef'ов), который передается шаблону Item в качестве параметра. Плюс я использую стандартную xpath-функцию count для подсчета количества полей.

Если теперь переключиться во вкладку Design, увидим, что ура, строка с нашим div'ом действительно появилась - но она почему-то пустая, в ней нет текста!

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

Не удалось? Не страшно, ведь всегда можно подсмотреть правильный ответ :)

Дело здесь в том, что мы вызываем шаблон PrintFieldWithECB для неверной выборки данных. Ведь раньше мы вызывали его из другого шаблона, а сейчас шаблон изменился, и естественно, что нужно обновить xpath-запрос. Правильным решением здесь будет просто заменить ../FieldRef на $Fields в xpath-запросе атрибута select элемента apply-templates.

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

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

До новых встреч!

SharePoint и XSLT: Развертывание через Visual Studio

2011-10-25T08:45:00.000+04:00

К настоящему времени, в рамках серии статей про SharePoint и XSLT, уже были освещены многие интересные моменты, включая довольно актуальные примеры (разбор еще множества примеров - впереди), но до сих пор мы не касались развертывания XSL-преобразований через Visual Studio. Эта информация очень важна для разработчиков SharePoint, но замечу еще раз - что посредством SharePoint Designer, XSL-преобразованиями в SharePoint могут пользоваться и администраторы, и дизайнеры, и ITPro.

Итак, сегодня мы узнаем:

Как подключать XSLT через CAML
Как программно подключить XSL-преобразование к списку
Чем отличаются свойства XslLink классов SPView и XsltListViewWebPart
Ограничения при использовании XSLT в Sandboxed solutions

Способы подключения XSLT

Как всегда, SharePoint предоставляет множество различных возможностей для работы с XSLT через Visual Studio. Например, мы можем подключать XSL-преобразования как к представлениям списков, так и непосредственно к веб-частям XsltListViewWebPart; делать это через CAML или через объектную модель; разворачивать XSLT-файлы в SharePoint Mapped Folders или в библиотеки документов.

Очень важно знать разницу между всеми этими способами - а она, поверьте, есть. И иногда она огромная.

Через CAML

К слову сказать, Collaborative Application Markup Language, в просторечии CAML - это вся совокупность XML-схем, которые могут быть использованы в целях расширения или настройки SharePoint'а. И если кто-то до сих пор думает, что CAML - это только схема Query, предназначенная для формирования запросов к спискам - нет, это не так, и вы легко можете в этом убедиться, внимательно почитав MSDN.

В общем, все эти модули, Elements.xml, List Batch API - это всё CAML. Это очень мощная и развитая система, хотя и не всегда удобная. Кстати, не так давно я написал отдельную статью о том, почему CAML в SharePoint - это плохо, и когда следует опасаться его использовать.

Если вернуться к нашим "баранам", CAML позволяет развертывать XSL-преобразования двумя способами:

Подключением к создаваемому шаблону списка
Подключением к разворачиваемой веб-части XsltListViewWebPart

Как видите, нет возможности подключить XSLT к представлению существующего списка, точно также, как нет возможности подключить XSLT к уже существующей веб-части. Это довольно существенное ограничение, которое нужно понимать и иметь в виду.

Но давайте посмотрим наконец, как это делается!

Для подключения XSLT-файла нужно, прежде всего, создать сам XSLT-файл и развернуть его, чтобы обеспечить его доступность из SharePoint. Для этой цели, я создал SharePoint Mapped Folder "Layouts", в нем - папку проекта, и в ней - файл HelloWorld.xsl, код для которого взял из статьи SharePoint и XSLT: Hello world!

Подключение к создаваемому шаблону списка

Следующий шаг - создать новый элемент List Definition, на основе любого существующего шаблона списка:

Теперь откроем файл Schema.xml и пролистаем до списка представлений (элемент <Views>), найдем представление "по умолчанию" (DefaultView="TRUE"), и найдем в нем элемент <XslLink>:

Как видите, по умолчанию, в качестве файла с XSL-преобразованием указан файл main.xsl. Естественно, можно его подменить. Но как указать на наш файл HelloWorld.xsl?

Поскольку файл main.xsl лежит по пути 14\TEMPLATE\LAYOUTS\XSL, то очевидно, что нам нужно указать путь ..\SharePointXslt\HelloWorld.xsl (SharePointXslt - это название проекта). Обратите внимание: элемент XslLink принимает путь к файлу, а не Url. Попробовав указать Url в любом варианте, мы непременно получим ошибку. Таким образом, к элементу <View> никаким образом нельзя подключить XSLT-файл, размещенный в библиотеке документов! Поскольку элемент <View> в объектной модели представляется объектом SPView, то и для него это справедливо.

Итак, получается, что через шаблон списка, мы сможем подключить только файл, расположенный в пределах 14 hive. Но означает ли это, что мы не можем подключать XSLT-файлы к шаблонам списков в Sandboxed Solutions? Вроде бы да: ведь SharePoint Mapped Folder в песочнице не работает!

Но решение есть! Оно довольно хитрое, и я сомневаюсь, что даже самые опытные из читателей знают это. Так что вот вам сакральные знания:

Xsl-файл можно цеплять из папки фичи!

Как известно, в песочнице можно разворачивать модули (элемент проекта Module). Файлы модулей традиционно сначала попадают в папку возможности (Feature), а уже потом загружаются в нужную библиотеку документов. И если указать путь к файлу модуля в фиче, относительно каталога, где лежит стандартный main.xsl, то это, как ни смешно, сработает :)

При этом, внутренности Elements.xml можно удалить: ни в какую библиотеку документов файл загружать нет необходимости.

Этот же трюк работает с программным заданием свойства SPView.XslLink.

Прошу обратить внимание на то, что это всё-таки трюк, и в одном из следующих обновлений его теоретически могут даже исправить, введя какое-нибудь security-ограничение. Вероятность крайне мала, но есть.

Поэтому, наверное, всё-таки лучше пойти более простым путем, и напрямую вписывать XSLT-код в тег <Xsl>. Этого тега по умолчанию в Schema.xml вы не найдете, но его можно легко добавить вместо <XslLink>. С этим подходом всё очень очевидно, надеюсь, сложностей здесь у ни у кого не возникнет.

Подключение к разворачиваемой веб-части

Второй CAML-вариант - это присоединение XslLink к разворачиваемой веб-части XsltListViewWebPart. Веб-часть эта может быть легко развернута с помощью тега <AllUsersWebPart>.

Стандартная последовательность действий в этом случае следующая:

Идем в нужный нам список (на страницу AllItems.aspx), переключаем страницу в режим редактирования (Действия сайта -> Редактировать страницу), и в контекстном меню представления списка выбираем Экспорт веб-части:
В результате, получаем xml-файл с расширением webpart, начинающийся тегом <webParts>.
В наш проект в Visual Studio, добавляем новый модуль (Module).
Удаляем из модуля Sample.txt.
Добавляем существующий элемент, в появившемся диалоге указываем какой-нибудь файл веб-частей, например, C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\SiteTemplates\sts\default.aspx
Переходим в Elements.xml, создаем внутри тега <File> тег <AllUsersWebPart>, прописывая в нем положение нашей веб-части на странице, и внутрь тега <AllUsersWebPart> наконец уже вставляем экспортированный xml из webpart-файла, заключив, естественно, его предварительно в CDATA:
```
<AllUsersWebPart WebPartZoneID="Left" WebPartOrder="1">
<![CDATA[
    <webParts>
        
    </webParts>
]]>
</AllUsersWebPart>
```

В общем, в итоге получим довольно длинный файл Elements.xml, с тегами Module -> File -> AllUsersWebPart. Эта конструкция развернет страницу default.aspx и добавит на неё веб-часть.

Соответственно, внутри тега <webParts> сложно не заметить теги <property>, которые как раз могут быть использованы для изменения свойств Xsl и XslLink объекта XsltListViewWebPart.

Кстати, в отличие от тега XslLink в элементе View, тег XslLink в XsltListViewWebPart принимает как раз Url'ы. То есть, можно указывать на библиотеки документов.

Однако, и здесь не обошлось без неприятностей :-( Оказывается, есть довольно серьезный "known bug", который не позволяет спокойно использовать подключение XSL-преобразований через свойство XslLink. Я писал об этом подробно в английском блоге, если вкратце: перестает работать контекстное меню элементов списка, а также перестают работать кнопки "Изменить элемент", "Просмотреть элемент" и "Удалить" на ленте.

Баг возникает только при использовании xsl-файлов из библиотек документов. В случае с файлами, развернутыми в _layouts - все работает прекрасно. Но как сами понимаете, для того чтобы развернуть файлы в _layouts, нужны полномочия администратора фермы...

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

В итоге, опять же приходим к тому, что лучше всегда использовать тег <Xsl> и прописывать преобразования напрямую в код внутри AllUsersWebPart. И выглядеть это, поверьте мне на слово, будет очень убого (потому что двойной CDATA сделать нельзя, и придется эскейпить "по старинке", через < и >)... :-(

Кстати, для того, чтобы использовать созданное Xslt-преобразование списка много раз, имеет смысл не пользоваться тегом AllUsersWebPart, а развернуть "преднастроенный" webpart-файл в галерею веб-частей. Тогда пользователи сами смогут добавлять эту веб-часть на нужные им страницы. Проблема абсолютной нечитаемости XSLT-кода остается, но в случае Sandboxed Solutions этот вариант вас, возможно, просто-таки спасет...

Программное подключение XSL-преобразований

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

Дело в том, что программный подход как минимум намного более урезан в Sandboxed Solutions. Например, веб-части недоступны из объектной модели в песочнице, также запрещен и класс SPLimitedWebPartManager. То есть работать с XsltListViewWebPart не получится совсем.

Впрочем, когда можно работать с SPView, опускаться до уровня веб-частей обычно и не требуется.

Но и c SPView тоже не все так просто. Есть неприятный баг, на этот раз, как раз при использовании свойства Xsl. Если вкратце - использовать это свойство невозможно :)

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

Никакие обманные пути не помогают: в свое время, убил порядка 4 часов на попытки обойти эту проблему. Так что SPView.Xsl лучше не пытаться использовать. Не получится :(

Таким образом, для Sandbox, остается только хитрый способ с подключением XSLT-файла из папки фичи, который я описывал выше.

Для farm-solutions все проще: есть возможность использовать XsltListViewWebPart, и есть возможность развертывать XSL-файлы в _layouts.

Программное подключение XSLT к представлениям списка

Давайте теперь посмотрим код:

public override void FeatureActivated(SPFeatureReceiverProperties properties)
{
    var web = properties.Feature.Parent as SPWeb;
    var list = web.Lists["Test"];
    var view = list.DefaultView;
    view.XslLink = @"..\..\FEATURES\SandboxTest_Feature1\XsltModule\Sample.xsl";
    view.Update();
}

Да, в основном такие вещи осуществляются в Feature Receiver, но хочу сразу же заметить, что забивать класс Feature Event Receiver простынями кода - вообще говоря нехорошо. Если у вас там планируется много кода, сразу разбивайте его на классы.

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

Как видите, всё довольно просто: получаем какой-то существующий список (с заголовком Test), и подключаем к его представлению "по умолчанию" существующий в папке фичи файл. Сам файл изначально лежит в модуле:

Важный момент! Вот такой вот код, выглядящий вроде аналогичным представленному выше:

public override void FeatureActivated(SPFeatureReceiverProperties properties)
{
    var web = properties.Feature.Parent as SPWeb;
    var list = web.Lists["Test"];
    list.DefaultView.XslLink = @"..\..\FEATURES\SandboxTest_Feature1\XsltModule\Sample.xsl";
    list.DefaultView.Update();
}

...работать не будет!

Дело в том, что DefaultView всегда создает новый экземпляр объекта, и поэтому list.DefaultView.Update() будет пытаться сохранить только что созданный, неизмененный объект... Более подробно можно почитать в посте Антона Вишнякова. В общем, будьте аккуратны: на эту ошибку напарываются довольно часто.

Для farm solutions, подключение XSLT-файлов работает аналогичным образом. Для обсуждавшегося в начале статьи файла HelloWorld.xsl, код будет выглядеть следующим образом:

public override void FeatureActivated(SPFeatureReceiverProperties properties)
{
    var web = properties.Feature.Parent as SPWeb;
    var list = web.Lists["Test"];
    var view = list.DefaultView;
    view.XslLink = @"..\SharePointXslt\HelloWorld.xsl";
    view.Update();
}

Да, еще один момент: получать список по заголовку не очень хорошо. Заголовок ведь кто угодно может изменить, поэтому более надежный способ - это метод GetListFromWebPartPageUrl.

Код изменится следующим образом:

public override void FeatureActivated(SPFeatureReceiverProperties properties)
{
    var web = properties.Feature.Parent as SPWeb;
    var list = web.GetListFromWebPartPageUrl("Lists/Test/AllItems.aspx");
    var view = list.DefaultView;
    view.XslLink = @"..\SharePointXslt\HelloWorld.xsl";
    view.Update();
}

Программное подключение XSLT к веб-частям

Здесь тоже ничего сложного нет, главное - не забывать освобождать использованные объекты :)

public override void FeatureActivated(SPFeatureReceiverProperties properties)
{
    var web = properties.Feature.Parent as SPWeb;
    var list = web.Lists["Test"];
    using (SPLimitedWebPartManager manager = web.GetLimitedWebPartManager(list.DefaultViewUrl, PersonalizationScope.Shared))
    {
        var xlv = (manager.WebParts[0] as XsltListViewWebPart);
        xlv.XslLink = "/_layouts/SharePointXslt/HelloWorld.xsl";
        manager.SaveChanges(xlv);
    }
}

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

Подводя итоги

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

Кроме перечисления способов и обсуждения отличий между ними, мы сегодня рассмотрели очень много ошибок и нюансов, и я искренне надеюсь, что эта информация поможет вам сэкономить немало времени на борьбу с, как всегда, сложноуловимыми багами SharePoint'а :)

Да, как всегда, если вам понравилась статья, не забудьте подписаться на мой блог! :) Любые комментарии приветствуются.

P.S. В следующей статье серии мы вернемся к рассмотрению "боевых" примеров использования XSLT.

Про XSLT и Visual Studio: отладка и intellisense

2011-10-18T16:00:00.000+04:00

По результатам публикации статьи SharePoint и XSLT: Hello world!, уже появились недовольные читатели, восклицающие в комментариях, что вот мол, использовать Блокнот/SharePoint Designer это непрофессионально... :) Примерно такие же отзывы я слышал и на RUSUG, где недавно читал доклад "SharePoint и XSLT".

И на самом деле я согласен, что будучи разработчиком, и имея такой мощный и многофункциональный инструмент, как Visual Studio, хотелось бы использовать его богатые возможности для работы с XSLT в SharePoint. Точнее, хотя бы попробовать это сделать :))

Ну вот давайте посмотрим, на что способна (или не способна?) Visual Studio.

Intellisense

Вот вроде как, "Подумаешь, XSLT intellisense в Visual Studio настроить. Легко!". Легко, да не совсем! Во-первых, в редакторе XSLT в студии просто нет интеллисенса для XPath. Во-вторых, нет xsd-схем для SharePoint'овских расширений XSLT. В свое время, потратил целый день, пытаясь найти хоть какие-нибудь XSD - безрезультатно. Те, которые лежат в каталоге 14\TEMPLATE\XML, не подходят.

Так что в плане intellisense, максимум что мы получим в Visual Studio - это автоподстановки и подсказки по стандартной схеме XSLT. Всё. #fail

SharePoint Designer в этом отношении на 5 корпусов впереди: в нем есть довольно продвинутый intellisense для XPath, поддерживается значительная часть тегов расширения, причем никакого ручного подключения файлов входных данных не требуется - они автоматически подхватываются из веб-части, для которой осуществляется редактирование тэга <Xsl>.

Отладка

Ок, но хотя бы отладку XSLT можно запустить из студии!? Уж в этом-то студия не должна подвести!

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

Впрочем, есть другой вариант: отладка через отдельное консольное приложение, через объект XslCompiledTransform. Если в конструкторе этого объекта указать параметр true, то это будет означать специальный отладочный режим. И тогда при нажатии F11 на строке вызова метода Transform, можно попасть в XSLT-файл, и типа всё будет "чики-поки".

Конечно, перед началом работы придется сдампить параметры преобразования и входной XML (dsQueryResponse), и потом подпихнуть их в XslCompiledTransform. Это немало работы, но она разовая, поэтому того стоит.

НО!

Есть еще ddwrt-функции и всякие ddwrt-атрибуты. Они подключаются через Extension Object. Класс, реализующий этот extension object, расположен в сборке Microsoft.SharePoint и помечен как internal. Как к нему доступиться? Разве что через Reflection..

Но есть еще одна неприятность: существует досадный баг в Visual Studio 2010 (даже с примененным SP1), когда пытаешься заниматься отладкой XSLT в .Net Framework 3.5. Он описан на Microsoft Connect: XSLT debugger doesn't work with in memory transformation.

Итог

В свете вышеописанного, я лично использую Visual Studio в простейшем варианте, практически как текстовый редактор... Хорошо еще, что сложных преобразований почти не бывает: 90% XSLT-кода копируется из стандартных файлов, собственного кода - очень немного. Необходимости в отладке пока практически не возникало.

Комментарии по этой заметке приветствуются. Я буду очень рад, если я не прав - сам разработчик, хорошие intellisense и debug очень ценю.

SharePoint и XSLT: Объединяем две колонки в одну

2011-10-17T09:10:00.000+04:00

Довольно часто возникает такая задача: объединить несколько колонок списка в одну при отображении. Обычно это требуется в следующих случаях:

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

В общем, объединение двух колонок в одну при отображении позволяет сэкономить место на экране, улучшить внешний вид, поправить usability, "вписаться" в брэндбук... Это требуется часто, поэтому важно знать, как это можно сделать.

Как видно из скриншота вверху, в качестве примера я решил использовать стандартный список "Tasks", в который добавил одну колонку типа "Multiple lines of text", и назвал её "PM's comment". То есть тот самый 4й вариант: такие комментарии слишком редки, чтобы для них держать целую колонку (да и колонка будет большая, потому что комментарий может содержать значительный объем текста) - но при этом очень важно их показать, если они всё-таки есть.

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

Эта задача прямо-таки идеальна для XSLT! Любые другие решения потребуют необоснованно больших трудозатрат. Если кто-то знает, как это можно легко и надежно сделать без XSLT - прошу оставить свои идеи в комментариях.

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

Скрыть столбец "PM's comment" из представления
Отобразить содержимое поля "PM's comment" в той же ячейке, где находится название задачи.

Скрыть столбец - довольно частая задача, и она реализуется средствами XSLT очень просто. Как я рассказывал в предыдущей статье серии, для определения, какой шаблон придется изменять, лучше всего использовать SharePoint Designer.

Открываем SPD, находим наш список, и открываем его представление "All tasks":

Очевидно, что для скрытия колонки нам потребуется скрыть два шаблона: для отображения заголовка этой колонки, и для отображения ячейки данных этой колонки. Довольно логично, что заголовок и ячейка данных отображаются разными шаблонами, не так ли? :)

Хорошо, давайте ткнем на заголовок нашей колонки, и затем в статусной строке выделим элемент <xsl:template>, первый слева от тега <th> (а точнее, он будет отображен как <th.ms-vh2>):

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

Теперь скопируем атрибуты выбранного нами тега <xsl:template>, выбрав в контекстном меню этого элемента Edit Tag...:

Временно сохраним этот код в любом текстовом редакторе. Отлично, а теперь то же самое нужно проделать с любой из ячеек данных нашей колонки - здесь нам потребуется шаблон, первый слева после тега <td>.

Получившиеся два тэга <xsl:template> нужно закрыть, т.к. при копировании из Edit Tag они получаются незакрытыми. А контент в них вставлять не нужно, т.к. мы их скрываем, а не заменяем.

Итак, можете проверить, вот что должно получиться в итоге:

<xsl:template 
    name="FieldRef_header.PM_x0027_s_x0020_comment"
    ddwrt:dvt_mode="header"
    match="FieldRef[@Name='PM_x0027_s_x0020_comment']"
    mode="header"
    ddwrt:ghost="" />
<xsl:template 
    name="FieldRef_printTableCell_EcbAllowed.PM_x0027_s_x0020_comment"
    match="FieldRef[@Name='PM_x0027_s_x0020_comment']"
    mode="printTableCellEcbAllowed"
    ddwrt:dvt_mode="body"
    ddwrt:ghost="" />

Обратите внимание: я удалил строку "hide" из атрибута ddwrt:ghost. Иначе, дизайнер стирал бы эти шаблоны при каждом переключении между вкладками Code и Designer.

Давайте удостоверимся, работает ли это?

Переходим на вкладку Code, отыскиваем XsltListViewWebPart, добавляем тег <Xsl>, в него вставляем стандартный xsl:stylesheet, подключаем через xsl:include файл стандартных преобразований main.xsl, и наконец, вставляем наш код. Напомню, откуда брать код для xsl:stylesheet и другие базовые вещи - я объяснял и подробно показывал в предыдущей статье серии: SharePoint и XSLT: Hello world!

Теперь переключаемся обратно - и видим, что колонка действительно пропала!

Особо отмечу, почему мы должны скрывать эту колонку именно через XSLT (ведь её можно скрыть и через GUI, перейдя в настройки отображения и сняв соответствующую галочку): дело в том, что если колонка не включена в представление, данные этой колонки не будут переданы и в XSLT, и мы просто не сможем получить значения этой колонки из нашего преобразования. А значения-то нам нужны: ведь мы всё-таки собираемся отобразить эту колонку, хоть и в другом месте.

Следующий шаг - изменить отображение колонки с названием ячейки. Для этого воспользуемся трюком с Conditional formatting, который я уже объяснял. Вкратце: выделяем любую ячейку колонки Title, жмем на Ribbon'е Conditional formatting => Format column, прописываем любое условие (например ID='0'), выставляем любой стиль, потом переключаемся во вкладку Code и смотрим, что получилось...

Ага! В тег Xsl добавился новый шаблон.

Этот шаблон идентифицируется атрибутами match="FieldRef[@Name='LinkTitle']" mode="printTableCellEcbAllowed", т.е. отображает ячейку с InternalName равным LinkTitle. Это служебное поле с типом Computed, оно получается из стандартного Title путем добавления ссылки на модальный диалог формы отображения элемента списка.

Шаблон в целом очень простой. Он почти ничего не делает: только выводит тег <td>, добавляет ему несколько атрибутов, и вызывает нижестоящий шаблон (mode="PrintFieldWithECB"). После вызова этого шаблона, мы можем добавить наш собственный код, который будет отображать наше поле PM's comment.

Даже имея самое скудное представление об XSLT, можно догадаться, что отобразить еще одно поле можно еще одним вызовом <xsl:apply-templates>, ведь очевидно, что содержимое поля LinkTitle отображается именно c помощью этого шаблона.

Но как же указать, что нужно отобразить именно поле PM's comment? Прежде всего, нужно получить уникальный идентификатор этого поля, чтобы на него ссылаться. Это очень просто: в листинге наверху вы могли заметить строку PM_x0027_s_x0020_comment - это собственно и есть InternalName нашего поля.

Дальше, изучив имеющийся apply-templates, можно догадаться, что атрибут select="." указывает на текущий обрабатываемый элемент. А текущий обрабатываемый элемент, как известно, задается с помощью атрибута match текущего шаблона. Т.е., сейчаc обрабатывается FieldRef[@Name='LinkTitle'], а нам нужно обработать FieldRef[@Name='PM_x0027_s_x0020_comment'].

Т.е. согласно правилам XPath, следует передать в apply-templates select="../FieldRef[@Name='PM_x0027_s_x0020_comment']". Давайте попробуем. Вот такой будет код у второго вызова apply-templates:

<xsl:apply-templates select="../FieldRef[@Name='PM_x0027_s_x0020_comment']" mode="PrintFieldWithECB">
    <xsl:with-param name="thisNode" select="$thisNode"/>
</xsl:apply-templates>

Переключаемся во вкладку Design, видим:

Отлично! Почти то, что нужно! Осталось только сделать это всё немного более приятным глазу.

Для этого, давайте заключим наш дополнительный вызов xsl:apply-templates в div, и добавим этому div'у стили. Но постойте! Если мы сделаем div c padding'ом, и пропишем ему еще и цвет фона - получится нехорошо, т.к. этот квадрат будет виден во всех записях, даже там, где поле PM's comment пустое.

Т.е. нам нужен условный вывод тэга. На самом деле это реализуется элементарно в XSLT - в нем есть специальный тег <xsl:if> для таких вещей. Как создавать условие - можно подсмотреть у Conditional Formatting. Помните же, мы задавали условие ID='0'? SharePoint Designer сгенерировал соответствующую строку для этого, её можно найти внутри тега xsl:attribute сразу после тега td. Очевидно, что если заменить в этом сгенерированном условии ID на PM_x0027_s_x0020_comment, и заменить ='0' на !='', то получится задать проверку на наличие нашего поля.

Вобщем, в итоге у меня получился вот такой код:

<xsl:if test="$thisNode/@PM_x0027_s_x0020_comment != ''">
   <div style="background-color:#FFEEEE; margin: 5px; padding: 4px 10px; font-size: 9px;">
      <xsl:apply-templates select="../FieldRef[@Name='PM_x0027_s_x0020_comment']" mode="PrintFieldWithECB">
          <xsl:with-param name="thisNode" select="$thisNode"/>
      </xsl:apply-templates>
   </div>
</xsl:if>

Конечно, к div нужно подключать css-класс, inline-стили написаны исключительно в качестве примера, для простоты.

Если теперь перейти к просмотру нашего списка в браузере, получим следующую картину:

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

Подводя итог, сегодня мы научились объединять две и более колонок в одну при отображении списка, и это - ценой всего 10 строк XSL-преобразования (остальные строки нам сгенерировал дизайнер).

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

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

P.S. Если вам понравилась статья, не забудьте подписаться на мой блог :)

SharePoint и XSLT: Hello world!

2011-10-13T12:13:00.000+04:00

Продолжаю серию статей про XSLT в SharePoint.

В предыдущей статье я рассказывал, почему XSLT в SharePoint - это важно.

Сегодня - перейду по-тихоньку к практике, и вы узнаете: как написать простейшее XSL-преобразование, как подключить его к списку, как выбрать шаблон для изменения, где подсмотреть примеры XSLT-кода, как выглядит дерево шаблонов веб-части XsltListViewWebPart, и еще много разных нюансов :) Поехали?

XSL-преобразования

Каждый наверное представляет, хотя бы примерно, что такое XSLT. Если сказать кратко, XSLT - это шаблон преобразования одного XML в другой, и сам представляющий из себя тоже разновидность XML :) Чаще всего, некий входной XML с данными преобразовывается в HTML, который затем отображается в браузере. Также происходит и в SharePoint, когда дело доходит до отображения данных списков, результатов поиска и др.

XSLT - язык очень мощный и богатый. Что нам нужно знать сейчас, это то, что основу XSLT составляют т.н. "шаблоны" (templates, элемент xsl:template), каждый из которых позволяет преобразовывать в HTML конкретный кусок входного XML. Подобно функциям, шаблоны могут вызывать друг друга (в том числе рекурсивно), передавать параметры и т.д.

Вторая важная деталь касательно XSLT - это тот факт, что шаблоны можно переопределять (override), и можно подключать файлы с шаблонами друг в друга, подобно библиотекам. Таким образом, всегда можно использовать по большей части стандартное преобразование, а в собственном файле просто переопределить один-два шаблона, которые нас непосредственно интересуют. Таким образом объем финального кода чаще всего бывает небольшим.

Но давайте же посмотрим, как это всё выглядит...

Hello world в SharePoint XSLT

Итак, давайте создадим самое простое XSLT-преобразование. Это можно сделать без Visual Studio и даже без SharePoint Designer. Очень просто и быстро:

Запускаем блокнот :)
Открываем в браузере http://ваш портал/_layouts/xsl/main.xsl
Копируем первый тэг (xsl:stylesheet) в блокнот. Там куча объявлений xmlns, которые впоследствии могут понадобиться, - и запоминать их нет никакой необходимости, т.к. всегда можно получить из стандартных файлов SharePoint.
Создаем тэг корневого шаблона, <xsl:template match="/"> - этот шаблон будет всегда выполняться первым. В качестве содержимого шаблона записываем строку Hello world!
Закрываем тэги, проверяем, должно получиться примерно следующее (я немного обрезал xsl:stylesheet, чтобы получше читалось):
```
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

    <xsl:template match="/">
        Hello RUSUG!
    </xsl:template>

</xsl:stylesheet>
```
Загружаем файл в любую библиотеку документов.
Открываем страницу с представлением списка, переходим в режим редактирования страницы, открываем настройки веб-части, и прописываем ссылку на наш xsl-файл.
Вуаля :)

Таким образом, мы создали уникальнейшее преобразование, чего угодно - в надпись Hello world :)

Конечно, это не совсем то, что может пригодиться нам в реальной действительности. Вы наверняка заметили, что в шаблоне мы прописывали атрибут match="/" - это означает, что переопределяется корневой, самый первый шаблон. А шаблонов, которые можно переопределить, на самом деле, великое множество. Естественным образом, возникает следующий вопрос:

Какой шаблон переопределять?

Чтобы ответить на этот вопрос, лучше использовать более мощный инструмент, SharePoint Designer (далее - SPD).

Итак, запускаем SPD, переходим к любому имеющемуся списку, в котором есть хотя бы одна запись, открываем его представление по умолчанию (All items), и выделяем какую-нибудь ячейку списка. Например, так:

И уже здесь, сразу же, мы получаем очень интересную подсказку в строке состояния внизу:

Ого! XSLT-разметка!

Как можно догадаться, в строке состояния отображается полный "путь" к выделенному элементу в XSLT-разметке. Используя маленькую стрелочку слева, можно промотать этот путь до шаблонов верхнего уровня (если нужно). Код тэга любого шаблона можно посмотреть, выбрав в контекстном меню соответствующего элемента пункт "Edit Tag...":

Что интересно, "путь" к выделенному элементу генерируется индивидуально для каждого конкретного элемента (т.е. туда захардкожено название колонки). И он отображается в "Edit Tag...", т.е. мы можем сразу же получить код для шаблона, который нам нужен (этот шаблон будет вдобавок визуально подсвечен дизайнером):

Это означает, что если мы в своем собственном xslt-коде добавим представленный выше тэг xsl:template, и в качестве его содержимого пропишем, к примеру, строку Hello world, то вместо значений заголовочной ячейки мы получим нашу тестовую строку!

Звучит отлично, давайте попробуем.

Переключаемся в режим Code:

Находим наш XsltListViewWebPart:

Добавляем в разметку XsltListViewWebPart элемент Xsl:

Создаем внутри Xsl-тэга элемент xsl:stylesheet, и в нем прописываем ссылку на стандартный файл main.xsl:

Код для xsl:stylesheet (все эти xmlns), как я уже упоминал выше, можно легко подсмотреть в файле main.xsl, или любом другом файле вот этого очень полезного каталога:

C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS\XSL\

Именно в этом каталоге располагаются файлы, на которые я впоследствии буду часто ссылаться: main.xsl, vwstyles.xsl, fldtypes.xsl и др.

Последним шагом, добавляем шаблон xsl:template - просто копируем его из Quick Tag Editor, а в качестве содержимого шаблона используем строку Hello world. У меня в конечном итоге получился следующий код:

<xsl:stylesheet xmlns:x="http://www.w3.org/2001/XMLSchema" xmlns:d="http://schemas.microsoft.com/sharepoint/dsp" version="1.0" exclude-result-prefixes="xsl msxsl ddwrt" xmlns:ddwrt="http://schemas.microsoft.com/WebParts/v2/DataView/runtime" xmlns:asp="http://schemas.microsoft.com/ASPNET/20" xmlns:__designer="http://schemas.microsoft.com/WebParts/v2/DataView/designer" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:msxsl="urn:schemas-microsoft-com:xslt" xmlns:SharePoint="Microsoft.SharePoint.WebControls" xmlns:ddwrt2="urn:frontpage:internal">

    <xsl:include href="/_layouts/xsl/main.xsl" />

    <xsl:template match="FieldRef[@Name='LinkTitle']" name="LinkTitleNoMenu.LinkTitle" mode="Computed_LinkTitle_body" ddwrt:tag="a" ddwrt:dvt_mode="body" ddwrt:ghost="">
        Hello world!
    </xsl:template>

</xsl:stylesheet>

Переключаемся обратно в дизайнер, смотрим:

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

Где взять стандартный XSLT-код?

Это можно сделать опять же с помощью SharePoint Designer, и снова через вполне интуитивный визуальный интерфейс.

Трюк здесь в следующем: в SPD есть очень интересная возможность, которая называется Conditional Formatting. С помощью этого механизма можно подсветить или как-то выделить нужную ячейку (столбец) или целую строку в зависимости от некоторых условий.

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

По-моему, это прекрасная возможность изучить, пусть и частично, SharePoint'овские XSLT-шаблоны и способы их изменения.

Давайте попробуем!

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

Щелкаем по нашей ячейке, на риббоне отыскиваем Conditional formatting, выбираем Format Column, - появляется диалоговое окно условий.

Условия эти нужны, чтобы применять форматирование не ко всем строкам, а только к подходящим под заданные условия. В принципе логично :) Но в данном случае, нам это неинтересно, поэтому мы можем задать совершенно любое условие, в том числе невыполнимое, например, "ID < 0":

Жмем Set Style, появляется еще одно диалоговое окно, в котором можно выбрать уже конкретный стиль форматирования. Например, изменить цвет фона (background-color), или размер шрифта (font-size)... Как не трудно догадаться, эти настройки в итоге мапятся в соответствующие css-атрибуты. Впрочем, это нам тоже не интересно, можно выбрать первый попавшийся стиль.

В общем, в конце концов нажимаем ОК, стили применяются, если условие у нас было невыполнимым - внешний вид списка никак не изменится, но зато, если перейти на вкладку Code, мы увидим, что у нашей XsltListViewWebPart появился сгенерированный тэг Xsl, с кучей кода.

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

<xsl:attribute name="style">
    <xsl:if test="$thisNode/@ID &lt; '0'" ddwrt:cf_explicit="1">background-color: #FFEAAD;</xsl:if>
</xsl:attribute>

После удаления этого куска, перед нами - девственно чистый исходный шаблон, который вы можете изменять, как вам вздумается. Рекомендую поизучать и поизменять этот шаблон в SharePoint Designer, на тестовом списке, и может быть, сразу попробовать реализовать пару каких-нибудь своих идей...

Но с помощью Conditional Formatting, можно вытащить только пару шаблонов. Вдоволь с ними наигравшись и поняв их возможности, у вас неизбежно возникнет очередной вопрос:

Где взять полное дерево шаблонов?

Дерево шаблонов веб-части XsltListViewWebPart довольно сложное, и полное его описание - отдельная задача. Но базовые сведения о структуре шаблонов для отображения представления списка вполне можно получить из вот этой статьи на MSDN: Overview of XSLT List View Rendering System.

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

Чаще всего требуются:

Корневой шаблон (/) - для добавления ссылок на скрипты и css-файлы (использовать нужно аккуратно, проверяя, не был ли уже этот же файл подключен ранее).
Шаблон RenderView - здесь выводится тэг <table> (т.е. здесь к нему можно добавлять стили) и производится перечисление отображаемых на текущей странице элементов списка. Также, отсюда вызываются шаблоны группировки и отображения промежуточных итогов. Этот шаблон - хорошая точка для старта самостоятельных исследований.
Шаблон Item - вывод <tr>, перечисление всех полей.
Шаблон PrintTableCellEcbAllowed - вывод <td>.
Подробно про переопределение отображения содержимого полей с помощью шаблонов типа Text_body можно почитать на MSDN: How to: Customize the Rendering of a Field on a List View.

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

C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS\XSL\

, в файлах vwstyles.xsl и fldtypes.xsl.

Подводя итог

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

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

До новых встреч! :)

SharePoint Designer

2011-10-11T21:15:00.000+04:00

Давно хотел написать :)

За первый год работы с SharePoint, не использовал SharePoint Designer (далее SPD) ни разу. Питая с еще времен Perl'а стойкое отвращение к FrontPage, всегда считал любые визуальные редакторы HTML чем-то вроде костылей для людей, которые пока еще не выучили HTML...

В общем, не помню с чего это началось, но пришлось мне всё-таки установить, в конце концов, это "лишнее" приложение на рабочий компьютер... Ну, а раз установил - то полазал, пощупал, посмотрел - что к чему. Оказалось: штука очень полезная (именно для разработчика), и от FrontPage там мало что осталось. А вот различных интересных вещей можно подсмотреть - множество. И вот уже полгода - без SPD, как без третьей руки :)

Нет, код конечно можно писать и без него, но постепенно SPD встал в один ряд с рефлектором, MSDN и с "investigate 14 hive" в плане исследований. А исследования у меня занимают нередко большую часть всего времени разработки какого-либо решения - потому что оказывается, что очень многое в SharePoint можно сделать имеющимися средствами, быстро и эффективно, сохраняя глубокую интеграцию с другими частями системы. И даже несмотря на то, что на исследования тратится очень много времени - результат, я считаю, того стоит.

Ну да, и демонстрировать какие-то вещи на докладах - тоже очень удобно именно через SharePoint Designer. И на SharePoint Conference Russia, и на последней RUSUG - использовал именно его для демонстраций.

SharePoint и XSLT: Почему XSLT - это важно?

2011-10-07T09:27:00.000+04:00

Начинаю серию статей по XSLT в SharePoint.

XSLT в SharePoint - чрезвычайно мощный инструмент, глубоко интегрированный в систему. Даже в предыдущей, 2007й версии, роль XSLT была довольно велика - преобразования использовались при отображении результатов поиска (CoreResultsWebPart), а также для кастомизаций отображения представлений и форм списков (DataViewWebPart и DataFormWebPart).

В 2010м SharePoint'е XSL-преобразования используются еще более интенсивно. Отображение представлений всех стандартных списков, кроме календарей, осуществляется теперь именно через XSLT (XsltListViewWebPart). Формы внешних списков также отображаются через XSLT (XlstListFormWebPart), так что тенденция видна невооруженным взглядом: поскольку данные в SharePoint представляются в виде списков, на которые завязано всё, то можно смело сказать:

Практически всё отображение данных в SharePoint'e осуществляется с помощью XSLT

В свете этой аксиомы, становится понятно, что для дизайнеров SharePoint, знание XSLT незаменимо. Иначе они не смогут ни поменять отображение различных стандартных типов полей в списках, ни сделать редизайн самого списка, ни переделать рендеринг списка с таблиц на div'ы - а я знаю, сделать это им очень хочется :)

Не менее важно знание XSLT и для других людей, работающих с SharePoint - программистов, IT Pro, администраторов. Именно через XSLT можно реализовать KPI-светофоры и эффект красного глаза, сгруппировать вместе несколько полей при отображении, переделать пейджинг на более приличный вариант, удалить или изменить ненравящуюся многим ссылку "Добавить новую запись", изменить поведение и внешний вид группировки, и т.д.

К примеру, мне удалось реализовать такую интереснейшую штуку, как иерархическое представление списка:

На создание этого представления ушло всего лишь около 3 дней работы. При этом, решение вполне универсальное, т.е. если в вашем списке есть Lookup-колонка, указывающая на этот же список - значит, ему можно за 2 минуты добавить иерархическое представление.

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

Представление списка можно изменять очень сильно. Например, мне удалось добиться вот такого результата при отображении стандартного списка "Контакты", в который я добавил несколько дополнительных колонок стандартных типов:

Особенности этого представления:

Часть полей являются как бы служебными, и отображаются уникально - это ФИО и аватар (стандартная колонка типа Hyperlink or picture). Эффект мокрого пола для аватара реализован с помощью библиотеки reflection.js.
Присутствует индикатор дней рождения. Этот индикатор, кстати говоря, полностью работоспособен и не зависит от вычисляемых колонок (с которыми бывают проблемы, т.к. на самом деле они обновляются только при изменении записи или колонки). За какое количество дней предупреждать о дне рождения - может быть задано специальной настройкой, передаваемой в качестве параметра через расширение ParameterBindings. С помощью другой подобной настройки можно задать отображение юбилеев - при этом стиль индикатора изменится.
Основная часть добавляемых полей отображается снизу от индикатора дня рождения (или от ФИО, если индикатор отсутствует). При этом, отображением разных типов полей занимается SharePoint. Т.е., например, если вы добавите в представление Lookup-колонку, она отобразиться в виде ссылки, и т.д.
Справа от ФИО расположена дополнительная панель для контактных данных. Это обычные поля, имеющие тип Single line of text или Hyperlink or picture - и их особое отображение реализовано с помощью метаданных SPField, которые в XSLT передаются опять же, с помощью ParameterBindings.
Представление полностью локализовано.
Представление поддерживает все стандартные возможности - группировку, сортировку, фильтрацию, соединение с другими веб-частями, выделение одного и нескольких элементов, контекстный Ribbon, и т.д.
Объем кода XSLT - всего 350 строк. Причем большая часть кода - это стандартные шаблоны, скопированные из OOTB файлов.

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

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

9 статей про SharePoint

2011-10-01T22:01:00.002+04:00

Прошло уже больше года с момента основания блога, и давно пора подвести некоторые итоги. За год, я опубликовал чуть больше 50 постов, большинство из которых - про SharePoint, и среди последних лично я выделяю девять, тянущих на звание "статья".

Я думаю, многие из моих читателей пропустили хотя бы 1-2 статьи из этого списка. Поэтому, милости прошу, чтиво на выходные:

Также, если кто-то вдруг не в курсе, в конце августа сего года я создал еще один блог, английский, и уже успел настрочить туда 6 постов, из которых два даже были опубликованы на сайте NothingButSharePoint.com:

Это связано с тем, что в данный момент активно изучаю английский язык, и желание совмещать приятное с полезным, думаю, логично :)

Чем плох CAML в SharePoint?

2011-09-01T22:30:00.000+04:00

В последнее время, я всё чаще и чаще пишу обертки для CAML. Началось всё, кстати, с моего любимого SharePoint 2010 Fluent Ribbon API, благодаря которому я очень глубоко изучил Ribbon. Кстати, ведь забыл в блог написать, всего пару дней назад, зарелизил версию 1.3! :)


Создание кнопки на ленте с помощью Fluent Ribbon

Дак вот, после Fluent Ribbon, на работе закодил Fluent List API, для программного создания списков. Идея примерно такая же: создаем ListDefinition, в нем - FieldDefinition'ы, потом есть ListController, ему в метод Create передаем описание списка и объект SPWeb - вуаля, список создан. Плюс там еще куча вкусных фишек, можно и представления создавать, и на заданные WebPart-страницы сразу же их выкладывать, и локализация поддерживается... В общем, пользуюсь с огромным удовольствием!

Потом была еще обертка для SharePoint Batch List API, для пакетной обработки списков. Делал для рабочих нужд, не очень универсально. Если доделаю - обязательно выложу в паблик.

Наконец, в последние дни усиленно кодю новый проект, SharePoint EcmaScript CAML Builder, предназначенный для работы с CAML запросами к спискам на стороне клиента. По задумке - это аналог знаменитого Camlex, но по синтаксису отличается: на JavaScript всё-таки нет возможности анализировать лямбда-выражения. Да и самих лямбда выражений, впрочем, там тоже нет :-)

Создание CAML-запросов с помощью CamlJS

К слову, Camlex в серверном коде я всегда стараюсь использовать. Читабельность повышается неимоверно, и вероятность ошибки ниже. Конечно, проект не идеален: хотелось бы больше compile-time validation, но хотя бы runtime сообщения об ошибках очень внятные - уже здорово :) В общем, рекомендую!

Подводя итог, тенденция видна невооруженным взглядом. Весь CAML - нуждается в обертывании (а это, по сути дела, весь SharePoint'овский служебный XML). Но почему? Давайте разбираться.

Чтобы понять, в чем проблема, нужно заглянуть внутрь SharePoint. Если вы когда-нибудь это делали, то должны знать: центральный объект всего SharePoint'а - это некий SPRequest. Именно через этот класс в конце концов проходит, ну как минимум, вся работа с данными. А если взглянуть в этот класс, то, о ужас, обнаруживается, что это не более чем wrapper Unmanaged кода!!

Связь с мифическим ядром :)

Да-да, оказывается, когда-то SharePoint был полностью Unmanaged проектом, и это ядро осталось с тех самых времен.

Ага, теперь-то понятно, откуда берутся все эти печально известные ошибки вида "Cannot complete this action. Please try again" :)

И если проследить путь CAML-кусков, которые мы переправляем SharePoint'у, то вы очень скоро обнаружите, что все эти XMLSchema в конечном счете передаются именно в SPRequest. Иными словами, вся обработка XML осуществляется в неуправляемом коде.

И вот в том самом мифическом ядре SharePoint'а, складывается впечатление, что существует несколько самописных XML-парзеров или препарсеров, чрезвычайно нежных и чувствительных к передаваемому им XML. По крайней мере, я ни разу не видел таких ошибок при использовании любого современного известного парсера...

Вот вам несколько ошибок XML-парзинга для примера:

То есть, получается, что базовые возможности XML не всегда поддерживаются. С другой стороны, говорят, парзер спокойно глотает некоторые не well-formed XML-строки (что еще больший нонсенс).

Итак, получаем следующее: XML-парзер явно кривоват. Но весь SharePoint завязан на CAML, без него не обойтись. Что делать? Решение естественное: генерировать код, который уж точно работает, и в котором никто не сможет уже поставить комментарий , и сломать всё :) Генерация позволит избежать повторяющихся ошибок, к тому же уничтожит вероятность опечаток, улучшит документированность и структурированность кода, ну и всё такое в общем :)

Мораль: используете сложный CAML-код - пишите программную обертку.

Видео доклада SharePoint Ribbon и Office 365

2011-08-31T11:18:00.000+04:00

Видеозапись моего доклада с SharePoint Conference Russia наконец-то опубликована (как, впрочем, и видеозаписи докладов всех других участников)!

Те, кто еще не смотрел, могут посмотреть.

Метаданные для SPField на стороне клиента

2011-08-30T09:00:00.008+04:00

В недавнем посте я предлагал способ для запоминания метаданных SPField. И вот сегодня еще раз убедился, что пошел правильным путем.

Возникла задача, получить метаданные поля на стороне клиента, используя SharePoint Client Object Model. Конкретно, нужно было получить все поля, помеченные как содержащие E-mail - у пользователей для простановки этих отметок есть соответствующий интерфейс.

В итоге, пришел вот к такой простейшей функции:

function getFieldAttribute(field, metadataKey) {

    /// <summary>

    /// This function gets metadata key

    /// </summary>

    var xml = field.get_schemaXml();

    var domElement = CUI.NativeUtility.createXMLDocFromString(xml);

    var attribute;

    if (domElement.firstChild.getAttributeNS != null && domElement.firstChild.getAttributeNS != undefined)

        attribute = domElement.firstChild.getAttributeNS('my', metadataKey);

    else

        attribute = domElement.firstChild.getAttribute('p1:' + metadataKey);

    return attribute;

Как видите, всё довольно просто. Когда расширять и интегрировать созданное решение просто - это хороший признак того, что делаешь правильно.

Использовать - примерно так:

var ctx = new SP.ClientContext.get_current();

var list = ctx.get_web().get_lists().getById(SP.ListOperation.Selection.getSelectedList());

var fields = list.get_fields();

ctx.load(fields);

// ... load items or whatever you need here

ctx.executeQueryAsync(onSuccess, onFailure);

function onSuccess() {

    var emailFields = new Array();

    var fieldEnumerator = fields.getEnumerator();

    while (fieldEnumerator.moveNext()) {

        var field = fieldEnumerator.get_current();

        var attribute = getFieldAttribute(field,'MyFieldType');

        if (attribute == 'Email')

            emailFields.push(field.get_internalName());

SharePoint и XSLT: содержание книги

2011-08-10T12:33:00.001+04:00

Думаю о возможности написания книги про XsltListViewWebPart. Материала уже набирается немало, ниже приведено примерное содержание того, что я уже могу написать.

Введение

1. Почему нужно использовать XSLT?

2. Когда использование XSLT вредит?

3. Где в SharePoint еще нет XSLT, но очень хотелось бы, чтобы был

SharePoint Designer

1. Почему всегда нужно начинать с SharePoint Designer

2. Conditional formatting

3. Как на самом деле работает Conditional formatting

4. Добавление XsltListViewWebPart через SharePoint Designer

5. Прямая правка Xslt через SharePoint Designer

6. Создание и подключение Xslt-файлов через SharePoint Designer

7. Границы применимости SharePoint Designer

Visual Studio

1. Настройка XSLT Intellisense

2. Применение XSLT-решений с помощью Visual Studio

3. Такие одинаковые, и такие разные - свойства XslLink и Xsl

4. Развертывание XsltListViewWebPart через Xml

5. Программное развертывание веб-части XsltListViewWebPart

6. Программное изменение SPView

7. Заметки по брэндингу

SPViewStyle

1. Что такое SPViewStyle

2. Стандартные SPViewStyle

3. Создание собственного SPViewStyle

4. Альтернативы SPViewStyle

XSLT-шаблоны

1. Формат входных данных

2. Шаблоны списка

3. Шаблоны группировки. Особенности реализации группировки на ajax

4. Шаблоны пэйджинга

5. Шаблоны для режима inplace-редактирования

6. Шаблоны полей

7. Шаблоны для блога

8. Шаблоны для форума

Вспомогательные шаблоны

(глава по каждому шаблону)

Тонкая настройка XSLT

1. Дополнительные параметры: ParameterBindings

2. Пример использования ParameterBindings

3. Локализация и стандартные параметры в XsltListViewWebPart

4. Настройка и отключение пейджинга

Большой пример

Вообще, планируются довольно интересные inline-примеры, в частности целая линия примеров по аватарам: например, как добавить аватары на форум, и т.п.

Пока немного сумбурно, но общий смысл, думаю, понятен.

От читателей хочется услышать:
- будет ли это востребовано?
- какие еще интересные моменты можно добавить к этой книге?
- советы/предложения по реализации

SMS и SharePoint

2011-07-29T16:27:00.001+04:00

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

Я имею в виду встроенную в SharePoint возможность отсылать SMS и даже MMS по протоколу Office Mobile Service Protocol. Протокол вполне продуманный: предусмотрена пакетная отправка сообщений и интерфейс для получения статусов доставки... В этом посте я расскажу, как можно этот самый OMS использовать в своих решениях, и какие бонусы можно получить.

Office Mobile Service в SharePoint

Как вы знаете, в SharePoint есть такая распространенная кнопочка "Alert Me", которая позволяет настраивать оповещения об изменении элементов списков или файлов в библиотеках документов. Также, подписываться можно не на конкретные элементы, а на целые списки. Это делается централизованно, через User Settings => My Alerts.

После выбора, на какой список мы хотим подписаться, или на какой элемент списка - отображается большая форма настроек, среди которых есть интересный пункт Delivery Methods.

Ага, вот они, наши SMS! Но по умолчанию, они задисейблены. Чтобы настроить их, переходим на сайт Central Administration, выбираем System Settings => Configure mobile account:

Здесь нам предложат ввести адрес веб-сервиса и логин-пароль.

Что вводить!? Во-первых, можно создать собственный такой веб-сервис, который бы принимал данные в формате OMS, и затем использовал любой другой сервис по отсылке SMS-ок. Также, свой сервис можно заставить рассылать и напрямую, через GSM Gate.

Процедура создания собственного веб-сервиса подробно описана на MSDN.

Но конечно же, писать целый веб-сервис совсем необязательно. Есть большое число SMS-провайдеров, которые уже прекрасно понимают OMS-протокол и готовы для использования. Список их представлен на сайте Microsoft.

Office Mobile Service в Outlook

OMS-вебсервис, если его всё-таки написать, можно использовать не только в SharePoint, но и в Microsoft Office Outlook.

Если настроить Outlook на OMS-сервис, мы получаем возможность отсылать текстовые сообщения (есть даже Preview, как это будет выглядеть на среднем мобильном телефоне); плюс есть возможность отсылать оповещения о событиях календаря на телефон.

Объектная модель для отсылки SMS

Также, в SharePoint есть возможность самостоятельно отсылать SMS-ки через объектную модель... Простой вариант кода будет выглядеть примерно так:

// Берем аккаунт из настроек веб-приложения, и получаем инстанс OMS веб-сервиса
SPMobileMessagingAccount account = webApp.OutboundSmsServiceAccount;
SPMobileMessageWebService messagingWebService = new SPMobileMessageWebService(account);

// Формируем сообщение
SPMobileMessageSmsBuilder smsBuilder = new SPMobileMessageSmsBuilder(account);

// Получатели
smsBuilder.AddRecipient(mobile_telephone_number);

// Разбиваем текст на фрагменты по 132 символа (размер одной SMS)
smsBuilder.StartTextMessage();
List<StringBuilder> messageParts = SplitLongMessage(message)
foreach (StringBuilder chunk in messageParts)
{
    smsBuilder.AddChunk(chunk.ToString());
}
smsBuilder.EndTextMessage();

// At this point, the smsBuilder.Message property holds the message as an SPMobileSmsMessage object.
String messageXml = smsBuilder.GetMessageXml();

// Отсылаем
SPMobileMessageDeliveryReport report = messagingWebService.SendMessage(messageXml);

Всё довольно прозрачно, документация по классам доступна на MSDN.

Код взят из статьи Overview of Mobile Messaging Development, там же вы можете посмотреть подробности и некоторые более сложные случаи (в частности, пакетную отправку).

Выводы

Итак, если мы хотим создать собственное решение для отправки SMS, нам в любом случае придется реализовывать сервис для отправки, и некий интерфейс для обращения к этому сервису. Причем, в любом случае для взаимодействия между сервисом и интерфейсом будет использоваться какой-то протокол или промежуточное хранилище данных. Если вовремя это понять и использовать протокол OMSP, то получим следующие бонусы:

Клиенты смогут использовать ваш сервис не только в SharePoint, но и в Outlook.
Клиенты смогут использовать ваш сервис для отсылки оповещений об изменениях в списках (My Alerts).
Есть сторонние решения, которые также рассчитаны на использование OMS - вы имеете отличный шанс получить небольшую денежку за каждую отправленную их решениями смску!
Клиент всегда может сменить провайдера, использовав вместо вашего сервиса - чужой, что многократно повышает географическую актуальность решения. К примеру, вы заключили договор с неким провайдером, который умеет отправлять SMS только по России. Но продукт продается и за рубежом...

В общем, на мой взгляд, OMS - это первое, на что должен посмотреть разработчик, который хочет внедрить в свое решение возможность отправки SMS.

Работа с XML в SharePoint из Javascript

2011-07-06T12:29:00.000+04:00

SharePoint очень тесно связан с XML. Все эти схемы полей и списков, определения элементов Ribbon, SharePoint Batch API, запросы SPQuery/CamlQuery - и многое другое. И если на стороне сервера всё более-менее понятно, там есть XmlReader/XmlWriter, XmlSerializer, XDocument и т.д., то что делать на стороне клиента?

Как обрабатывать XML, формировать или изменять его, и какие для этого есть функции в SharePoint EcmaScript - всю эту информацию я постарался собрать в сегодняшней статье.

XmlWriter

Впрочем, XmlWriter в SharePoint всё-таки есть. Располагается он в пространстве имен SP (т.е. SP.XmlWriter), а физически - находится в SP.Core.js. Применение в целом аналогично серверной версии, но поддерживаются только следующие методы:

create(stringBuilder)

writeStartElement(tagName)

writeElementString(tagName, value)

writeEndElement()

writeAttributeString(localname, value)

writeStartAttribute(localname)

writeEndAttribute()

writeString(value)

writeRaw(xml)

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

var camlQuery = new SP.CamlQuery();
var sb = new Sys.StringBuilder();
var writer = SP.XmlWriter.create(sb);
 
writer.writeStartElement("Where");

writer.writeStartElement("Eq");

writer.writeStartElement("FieldRef");
writer.writeAttributeString("Name", "StatusID");
writer.writeEndElement();

writer.writeStartElement("Value");
writer.writeAttributeString("Type", "Integer");
writer.writeString("1");
writer.writeEndElement();

writer.writeEndElement();

writer.writeEndElement();
 
writer.close();
 
camlQuery.set_viewXml(sb.toString());
 
// Result: <Where><Eq><FieldRef Name='StatusID' /><Value Type='Integer'>1</Value></Eq></Where>

Еще, при формировании XML может пригодиться вот этот метод:

SP.Utilities.HttpUtility.escapeXmlText

, как не трудно догадаться из названия, этот метод эскейпит строку так, чтобы её потом можно было использовать в name или value xml-элементов и атрибутов.

Конвертируем объекты в XML

Конечно, XmlWriter это здорово, но даже на стороне сервера его редко кто использует, потому что есть гораздо более интересные варианты. Например, XmlSerializer.

И если немного поискать, то действительно, в файле SP.Runtime.js можно обнаружить методы SP.DataConvert.writeDictionaryToXml и SP.DataConvert.writePropertiesToXml. И они действительно сериализуют js-объекты... Но, использовать их врядли получится. Дело в том, что эти методы всегда генерируют теги Property.

Например, вот такой код:

var sb = new Sys.StringBuilder();
var writer = SP.XmlWriter.create(sb);
var context = new SP.SerializationContext();
var dict = { hello: "world", complexObject: { property1: "value1", property2: "value2"} };
var fields = ["hello", "complexObject"];
SP.DataConvert.writeDictionaryToXml(writer, dict, "root", fields, context);
// Значение сгенерированного XML можно теперь получить через sb.toString()

Сгенерирует строку с вот таким XML:

    <root>
        <Property Name="hello" Type="String">world</Property>
        <Property Name="complexObject" Type="Dictionary">
            <Property Name="property1" Type="String">value1</Property>
            <Property Name="property2" Type="String">value2</Property>
        </Property>
    </root>

Как видите, практическая ценность обоих этих методов весьма невелика. Поэтому, на практике я стараюсь везде где можно использовать json, или преобразование json в XML (например, с помощью соответствующего jQuery-плагина).

Парзим XML

Вообще, лучше jQuery для того, чтобы распарзить XML, по моему скромному мнению - ничего нет :) Делается это очень просто:

var jQueryObjectFromXml = $(xmlString);

, и дальше уже делаем всё что угодно с полученным jQuery-объектом...

Впрочем, по умолчанию jQuery в SharePoint отсутствует, поэтому иногда может пригодиться и метод из SharePoint, который превращает XML в DOM-объект. Этот метод называется CUI.NativeUtility.createXMLDocFromString и расположен в файле CUI.js.

Пользоваться довольно просто. Пример:

var domElement = CUI.NativeUtility.createXMLDocFromString('<root><child name="hello world"/><child>test value</child></root>');
 
domElement.firstChild.nodeName
// "root"
 
domElement.firstChild.firstChild.attributes[0].value
// "hello world"
 
domElement.firstChild.lastChild.text
// "test value"

Итоги

Традиционно, подводим итоги :) Работать с XML в SharePoint приходится довольно часто, в том числе и на стороне клиента, из JavaScript. И как всегда, в SharePoint обнаруживается довольно большое количество интересных объектов и методов, которые можно использовать в собственных целях. Документация по этим возможностям, к сожалению, чаще всего очень скудная - или отсутствует совсем. Поэтому, изучать приходится самостоятельно.

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

Использование HTML5 в формах списков SharePoint

2011-07-05T10:00:00.003+04:00

Недавно я писал про RenderingTemplate и использование перегруженного ListFieldIterator для того, чтобы изменять отображение форм списков SharePoint. В качестве примера использования этого способа, я привел скриншот проекта, где поля списка распределены по вкладкам. Также, в том посте был выложен для скачивания "базовый" проект-пример на эту тему.

Сегодня я хочу еще раз вернуться к RenderingTemplate и ListFieldIterator, рассмотрев их более тщательно и иллюстрированно, на другом примере - внедряя элементы управления HTML5 в формы списков SharePoint.

Что это дает?

Как вы наверняка знаете, HTML5 добавляет множество крайне интересных типов элементов управления, в числе которых:

Модифицированное html5-поле
Expires из стандартного списка
"Announcements",
вид из браузера Opera

элемент управления для выбора даты/времени
элемент управления для ввода телефонного номера
элемент управления для ввода адреса электронной почты
элемент управления для ввода URL

Есть и другие, полный список можно найти на W3Schools. Помимо типа элементов, добавились также и атрибуты, например, мне очень нравится встроенная валидация с помощью атрибутов required и pattern. Очень интересны также списки-подсказки (атрибут list) и текст-подсказка (атрибут placeholder). Т.о., использование HTML5 позволяет серьезно сэкономить на размере страницы, улучшить её производительность за счет отказа от javascript-решений, использовать оформление и локализацию браузера.

К сожалению, список браузеров, поддерживающих HTML5-элементы управления, очень невелик. Лучшая реализация сегодня - у Opera, на втором месте Chrome, все другие браузеры очень ощутимо отстают. Причем, в Опере SharePoint вообще ведет себя неважно - некоторые скрипты не работают, иногда неверно отображается дизайн, и т.д.

Поэтому, вынужден признать, что основная практическая ценность данной статьи - в объяснении приемов подмены полей, а не в добавлении HTML5 на формы :( Возможно, через некоторое время всё изменится, когда во все современные браузеры добавят поддержку форм HTML5. Я на это очень надеюсь (ибо возможности действительно классные)!

Rendering Template

Давайте же уже приступим к делу! Первым делом, создаем проект SharePoint Empty Project, и добавляем в него SharePoint Mapped Folder CONTROLTEMPLATES. Внутри этой папки, создаем User Control, и называем его Html5ListForm.ascx:

Копируем туда код из стандартного шаблона отображения ListForm, который вы можете найти в файле 14\TEMPLATE\CONTROLTEMPLATES\DefaultTemplates.ascx. Не забываем также скопировать и весь требуемый заголовочный код (<%@ .. %>).

Далее, ищем контрол ListFieldIterator и заменяем его на его же наследника:

<%@ Register Tagprefix="my" Namespace="Html5ListForms" Assembly="$SharePoint.Project.AssemblyFullName$" %>
<!-- skipped for clarity... -->

<SharePoint:RenderingTemplate ID="Html5ListForm" runat="server">
    <!-- skipped for clarity... -->

   <my:Html5FieldIterator ID="ListFieldIterator1" runat="server"/>
    
    <!-- skipped for clarity... -->
</SharePoint:RenderingTemplate>

FormsModernizr

Вслепую подключать HTML5 нехорошо и неправильно. Для определения, поддерживает ли браузер те или иные функции HTML5, существует специальная js-библиотека, которая даже была включена в состав ASP.Net MVC. Называется эта библиотека - Modernizr, но работает она на стороне клиента. А хотелось бы использовать ее на стороне сервера, ведь иначе никакой экономии в размере страницы не получится...

И вот недавно я как раз наткнулся на реализацию server-side modernizr на PHP. Идея довольно простая: при первой загрузке, все сведения из modernizr сохраняются в cookies, потом страница сразу же перезагружается, а после этого клиентский modernizr уже не нужен, и можно спокойно осуществлять любые проверки на стороне сервера, выпарзивая нужные сведения из cookies.

Недолго думая, написал крохотный контрол, который реализует эту идею.

Этот контрол, как не трудно догадаться, тоже следует добавить в RenderingTemplate, куда-нибудь повыше:

<my:FormsModernizr ID="FormsModernizr1" runat="server"/>

Я назвал этот контрол FormsModernizr, поскольку он позволяет определять только поддержку новых типов элементов управления и их атрибутов для html-форм. Другие возможности Modernizr'а не используются.

В этом контроле я перегрузил метод OnLoad, в котором проверяю, есть ли уже cookies с данными из клиентского Modernizr'а. Если кукисы еще не поставлены, то с помощью Page.Response.Write рендерим простейшую html-страницу, содержащую:

Скрипт Modernizr, который определяет, какие фишки HTML5 доступны
Функцию stringify, для преобразования объекта Modernizr в json-массив
Код для простановки cookies
Код для перезагрузки страницы

Далее, вызываем Page.Response.End - страница отсылается клиенту, Modernizr определяет возможности браузера, эти сведения сериализуются и попадают в кукисы. После этого страница перегружается.

Случай disabled cookies также корректно обрабатывается ;).

Если cookies наконец-то получены, то json-строка десериализуется (с помощью DataContractJsonSerializer) в статический объект FormsModernizr.Data. Ок, теперь можно использовать этот объект в классе, ответственном за отображение полей.

Html5FieldIterator

Следующий шаг - это создание класса Html5FieldIterator, который собственно и будет отображать поля. Идея состоит в перегрузке метода Render, и использовании коллекции SPContext.Current.FormContext.FieldControlCollection для стандартного отображения полей.

Для того, чтобы пометить некоторые нестандартные типы полей, которые нельзя определить по FieldType (например, поле для хранения номера телефона: у него FieldType = Text, а html5 type='tel'), мы будем использовать метаданные. Про метаданные для SPField я рассказывал в предыдущем посте.

Обычно, я еще дополнительно делаю ApplicationPage для настройки метаданных полей, и подключаю ссылку на неё на страницу настроек списка (List Settings). Но в этом примере, метаданные для полей можно просто расставить вручную, что я и сделал в FeatureReceiver.

Тип поля определили, но вот как теперь срендерить наши замены для полей?

Сделать это на самом деле довольно просто, можно воспользоваться даже несколькими разными способами. Например, довольно перспективно выглядит вариант с использованием Html Agility Pack, когда все контролы рендерятся стандартными средствами, после чего результат загружается в объект HtmlDocument, выбираются нужные элементы типа input, и им выставляется нужный тип...

Можно пойти более примитивным, но одновременно - более надежным путем, не полагаясь на html-парзинг, и полностью срендерив нужные input'ы. При этом, чтобы форма не сломалась, этим input'ам следует проставить правильные атрибуты id и name, которые бы корректно понимались SharePoint'ом. Брать эти атрибуты следует как раз из той самой коллекции правильных контролов, SPContext.Current.FormContext.FieldControlCollection, на серверной стороне они называются UniqueId и ClientId.

Код метода, заменяющего поле, у меня получился вот каким:

private static void RenderHtml5Field(HtmlTextWriter output, BaseFieldControl fieldControl, string fieldType)
{
    if (fieldControl.Field.Required && FormsModernizr.Data.Input.Required)
    {
        output.AddAttribute("required", "required");
    }
 
    output.AddAttribute("type", fieldType);
    output.AddAttribute("id", fieldControl.ClientID);
    output.AddAttribute("name", fieldControl.UniqueID);
    output.RenderBeginTag(HtmlTextWriterTag.Input);
    output.RenderEndTag();
}

Перед вызовом этого метода, fieldType определяется через метаданные поля, и проверяется, поддерживается ли такой тип поля браузером - через FormsModernizr.Data. Если тип не поддерживается, рендерится стандартный контрол. Более подробно можно посмотреть в проекте-примере.

Итоги

Итак, сегодня мы детально изучили процесс подмены контролов на формах списков SharePoint, познакомились с тем, как можно использовать Modernizr на стороне сервера, и может быть, немного подизучили HTML5 :)

Замечание: Решение не будет работать в Office365 и вообще в песочнице, поскольку ascx-файл с нашим RenderingTemplate'ом должен попасть в папку CONTROLTEMPLATES, а эта возможность для Sandboxed Solutions заблокирована.