Андрей Маркеев: SharePoint блог

Cisar

2015-10-11T00:37:00.001+03:00

В этом году я сделал одну большую вещь - Cisar. Это встроенное в браузер (точнее в F12 DevTools) мини-IDE, предназначенное для создания CSR (Client Side Rendering) кастомизаций в SharePoint. Главная фишка Cisar'а в том, что он поддерживает Live Preview, т.е. набираем код и сразу же, в реальном времени, видим результаты его работы на странице.

Это позволяет работать очень эффективно и создавать решения по кастомизации форм буквально за считанные минуты. Не шучу. Был даже реальный случай: коллега на работе оценил некоторую задачу по кастомизации форм в час работы, там надо было заменить текстовое поле dropdown'ом, причем он (коллега) с CSR очень хорошо дружит. Я с ним поспорил на пиво, что смогу сделать за 3 минуты с помощью Cisar. Проиграл: сделал за 5 :)

Поддерживается CSR для:

Форм списков
Представлений списков
Представлений списков в режиме Quick Edit

НЕ поддерживается на данном этапе CSR для результатов поиска, и вообще Display Templates как класс. Надеюсь это добавить в будущем, но это технически нетривиально.

До последнего времени Cisar плохо работал с не-root сайт-коллекциями, но у меня наконец-то дошли руки это поправить и теперь проблем быть не должно. Но версия все еще Beta, так что огромная просьба, всем кто будет использовать, пишите багрепорты!! Сюда в комментарии, или на GitHub, куда-нибудь в общем... :)

Cisar полностью бесплатен, open source, лицензия "Public Domain" (это означает, делайте вообще все что угодно с ним, никаких ограничений).

С технической точки зрения Cisar - это расширение для Chrome, написанное кстати на TypeScript. Для подсветки синтаксиса используется редактор codemirror. Для отображения списка файлов используется KnockoutJs. Для Live Preview используются результаты нескольких недель копания в кишках CSR, если вы думаете что это просто eval, можете посмотреть код :)

Исходники доступны на GitHub.
Само расширение можно скачать из Chrome Web Store.

Также, если кто-то вдруг пропустил мои статьи по CSR, с множеством примеров кастомизаций (большинство из которых были созданы с помощью Cisar), ссылки ниже (статьи на английском):

P.S. На самом деле так привык к Cisar, и так удобно, что теперь уже даже пытаюсь его использовать для любого клиентского кода. И как я раньше писал JSOM-код без intellisense!? :)

Про собеседования

2015-10-09T01:53:00.001+03:00

Прочитал статью Get that job at Google, и очень сильно разочаровался! Ситуация подтвердилась и другими источниками: оказывается, в больших компаниях типа Google и Facebook собеседования далеко не такие качественные, как можно было бы подумать :(

В частности, я был крайне удивлен что проведение технических собеседований доверяется обычным программистам без серьезной подготовки их для этой работы. И они приносят собственновыдуманные вопросы, скорее всего не прорецензированные более опытными коллегами... В итоге имеем что имеем: например, требуют писать код на доске (whiteboard), задают алгоритмические задачки олимпиадного типа и прочую чушь, с которой обычный программист никогда не имеет дела в реальной жизни (в том числе они сами). В итоге собеседование превращается в экзамен и приводит к огромному числу неправильных оценок кандидатов, причем ребята из Google утверждают, что это исключительно "false negative", тогда как я почти уверен, что "false positive" там тоже немало.

Я давно интересуюсь собеседованиями, и есть кое-какой опыт в этой области, причем побывал на обеих "сторонах баррикад": составлял вопросы и проводил собеседования когда работал в Softline; ну и конечно приличное количество раз ходил собеседовался в разные компании - в Костроме, Москве, Питере и Хельсинки, включая например Microsoft (кстати, за последние 5 лет не услышал ни одного отказа: 100% собеседований были успешными и заканчивались предложением работы).

Итак, ниже мои мысли по тому что нужно проверять на собеседованиях и как, и что не нужно, и почему.
Читать дальше »

Своё контекстное меню в JsGrid

2014-10-22T10:15:00.000+04:00

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

В прошлом посте я объяснял, как устроена система событий JsGrid, и оказывается, как раз с помощью события SP.JsGrid.EventType.OnRightClick - можно решить задачу с контекстным меню. Помимо события, впрочем, надо еще уметь само контекстное меню создавать. И оказывается, JsGrid имеет API и для этого тоже!

Система событий JSGrid

2014-10-21T09:30:00.000+04:00

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

Выделение цветом важных данных… в JSGrid!

2014-10-20T09:00:00.000+04:00

Пока дефинишены пишутся, решил написать про некоторые простые методы работы с JSGrid, на примере подсветки данных в гриде.

Также в статье приводится довольно много сведений общего плана про JsGrid, которые очень важны для понимания, как это все работает.

Читать дальше »

Документирую SharePoint JSGrid

2014-10-14T09:00:00.000+04:00

Тружусь сейчас над TypeScript-дефинишенами для JsGrid. Работа долгая и тяжкая: для каждой-каждой функции в JS файле из 24.5k строк нужно определить типы параметров и возвращаемого значения, понять что эта функция делает, и все это описать. Потратил уже несколько дней, по 5+ часов, и пока еще только в начале пути... Между прочим, даже главный шарепойнтовский файл, SP.debug.js, имеет меньший размер - ~21k строк...

Скриншот процесса:

Ускоряем SharePoint-разработку

2014-10-11T16:30:00.000+04:00

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

Однако, тестировать SharePoint-решения не так-то просто. Их ведь надо еще задеплоить. А пока деплоишь, заснуть можно!... И потом сиди вспоминай, что вообще протестировать-то хотел...

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

Смешно сказать, но я до сих пор вспоминаю SPVisualDev, расширение для Visual Studio для работы с SharePoint 2007. Мгновенное развертывание в 12 hive, отличная поддержка удаленной разработки и отладки, всё удобно, быстро и просто. Этого в SharePoint Developer Tools нет и в помине даже сейчас, в 2014!...

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

Тем временем во "внешнем мире"...

Проект IDE Light Table набрал $300k на Kickstarter. Основная идея проекта - в "живой разработке", когда IDE всегда находится в режиме отладки (!). Т.е. обычного режима не-отладки просто не бывает. Только начали писать код - тут же можно смотреть состояние переменных, и т.д.
Многие современные IDE поддерживают режим "live development". Пример - опенсурсная IDE Brackets. Вот одноминутная демка:
Visual Studio и ASP.Net развивают проект "Browser Link". Идея состоит в том, чтобы инжектить Signal-R скрипт на страницу, что позволяет в дальнейшем этой страницей управлять: релоадить целиком или частями, изменять, и т.д. "Browser Link" можно расширять с помощью Visual Studio extensions. В составе Web Essentials есть несколько крайне интересных расширений такого плана. Скотт Хансельман в этом 4х-минутном видео подробно все это демонстрирует:
Visual Studio "14" CTP 4 по умолчанию использует open source компилятор Roslyn, который имеет расширенные средства для работы с неполными синтаксическими деревьями, благодаря чему им удалось сделать on-fly incremental compilation. Идея в том, чтобы пропустить шаг Build. Т.е. меняем код, сохраняем, переходим в браузер, F5 - и смотрим изменения.
Помимо общеизвестного jsFiddle, появляется все больше и больше других Fiddle'ов, крайне интересных! Например, проект dotNetFiddle не только позволяет писать C# код онлайн, но также предоставляет режим, в котором можно тестировать полномасштабное ASP.Net MVC приложение (выберите Project Type: MVC)!

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

Оказывается, и в SharePoint тоже можно сделать немало!

Для начала, продолжая мысль из поста про скрытую прелесть provider-hosted Apps, ну как бы все современные вещи можно там использовать без ограничений :) Так что всё что выше описано, нам по большому счету тоже доступно. Надо просто не забыть воспользоваться.

Во-вторых, кратко вернусь к SPVisualDev. Это open source расширение было написано ОДНИМ человеком в 2008 году. Получается, не настолько уж это и сложно?... ;)

Дальше. Давайте подумаем про BrowserLink. Можно ли что-то похожее использовать в SharePoint? Я думаю - да. Ведь BrowserLink это ни что иное, как банальный SignalR. Если заинжектить аналогичный SignalR скрипт в masterpage SharePoint-сайта, то мы получим точно такое же "живое" соединение Visual Studio и SharePoint. Я думаю можно просто выдрать из страницы то, что Visual Studio инжектит, и запихнуть в SharePoint, и оно будет работать. Не успел проверить пока.

Дальше. А что насчет jsFiddle и ASP.Net MVC fiddle? Можно ли сделать собственный SharePoint fiddle? ДА БЕЗ ПРОБЛЕМ! Вот например оцените, проект JSON fiddle:

Блог пост: Introducing JSOM fiddle SharePoint app
В Office Store: JSOM fiddle app
Исходный код на Github

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

Моя попытка: CamlJs-Console

Вообще, на удивление, многие вещи не настолько сложные, как кажутся. Примерно в середине сентября я начал работать над крайне интересным проектом под названием CamlJs-Console. Это расширение для хрома, позволяющее создавать CamlJs-запросы в режиме live development, очень похожем на пример выше про Brackets. Пишешь - и сразу же видишь результат.

Оказалось, что Chrome Extensions пишутся на HTML+CSS+JavaScript. Очень просто. При желании можно даже создавать Chrome Extension + Web App (или даже SharePoint App) из одного исходного кода...

БЛИН! Я когда только-только сделал самую первую версию у себя на локальной машине в 3 часа ночи :), я сидел тестировал и не мог остановиться. Это настолько отличалось от вот этого "поправил-5 минут деплой", что чувствовалось как магия какая-то. Серьезно :)

Общий вид:

А вот live preview данных из списка:

Мне даже удалось подцепить туда интеллисенс (на основе TypeScript Language Service - ведь как известно, TS является расширением над JS, т.е. любой валидный JS-код является также и валидным TS-кодом):

И более того, мне даже удалось сделать интеллисенс лучше, чем TS-интеллисенс в Visual Studio! Потому что ведь у меня были живые списки. И их поля... :)

Мне кажется, получилось здорово! И заняло каких-то пару недель, причем большую часть времени возился с интеллисенсом.

Преимуществ у Chrome Extension немало: не надо аутентифицироваться, не надо ничего ставить на сайт (в отличие от того же SharePoint App). Можно тестировать и онлайн сайты, и на dev виртуалке, и что особенно ценно - зайти на production и там проверить запрос, на реальных данных (!). Интеграция работает через JSOM, но можно реализовать вариант на веб-сервисах (через SPServices например), и тогда будет работать даже с SharePoint 2007 (сейчас только SP2010 и SP2013).

Что дальше?

Ооооо... у меня полно идей, просто миллион! Можно делать extension'ы наподобие CamlJs - для работы с конкретным API, решения конкретных проблем. Можно делать более широкопрофильные, наподобие JSOM fiddle, но именно в виде Chrome extension. Можно копать в сторону интеграции Visual Studio и SharePoint, создания чего-то похожего на BrowserLink. Можно подумать о гибридных решениях, Visual Studio -> Chrome Extension -> SharePoint.

И это все может значительно улучшить наш процесс работы с SharePoint. Значительно!

Коллега с работы делает сейчас потрясающую штуку, как раз под впечатлением от CamlJs-Console. Крайне легко делается, но возможности открываются потрясающие. Смысл в том, что в Chrome через F12 можно редактировать файлы, подгруженные на страницу. Но конечно эти изменения никуда не сохраняются. Ну а вот он сделал так, что сохраняются, обратно в SharePoint :) И кода там - 50 строк :))). Проект пока на супер-начальной стадии, поэтому если захочется потестировать, тестируйте аккуратно и только на dev-окружении please :) Ссылка вот.

Заключение

Я из всей этой истории главное вот что понял: все в наших руках. Не надо ждать MS или еще кого. Мы сами можем.

P.S. Если у кого есть идеи/мысли на этот счет, с удовольствием поучаствую в обсуждении - кидайте комментарии! :)

Загадочно бесполезный SPList.GetDataTable

2014-09-22T09:20:00.000+04:00

Копал SPQuery в dotPeek, и наткнулся на интересный кусок кода:

if (this.m_Query.ConsiderManagedPipe
    && this.m_Query.SafeArrayFlags == null 
    && (this.m_Query.CalendarDate == DateTime.MinValue && !this.m_Query.IncludeMandatoryColumns) 
    && (this.m_Query.ViewFieldsOnly 
        && (this.m_Query.DataTableOptions & SPListGetDataTableOptions.RetrieveLookupIdsOnly) != SPListGetDataTableOptions.None 
        && ((this.m_Query.DataTableOptions & SPListGetDataTableOptions.UseBooleanDataType) != SPListGetDataTableOptions.None 
        && (this.m_Query.DataTableOptions & SPListGetDataTableOptions.UseCalculatedDataType) != SPListGetDataTableOptions.None)) 
    && (!string.IsNullOrEmpty(this.m_Query.ViewFields) 
    && string.IsNullOrEmpty(this.m_Query.ViewAttributes) 
    && (this.m_List.BaseType != SPBaseType.DiscussionBoard && !this.QueryIncludesMultiValueLookup(this.m_Query.ViewFields)) 
    && !this.m_List.HasUniqueScopes))
{
      ULS.SendTraceTag(963012918U, (ULSCatBase) ULSCat.msoulscat_WSS_Database, ULSTraceLevel.Verbose, "SPListItemCollection.EnsureListItemData: Retrieving data through the managed pipe.");
      this.m_bUseManagedPipe = true;
}

Интересно, думаю. Неспроста! Сами посмотрите: условия все такие, логически связанные с performance. Может это какой-нибудь хитрый performance-boost такой?

Ну, начал разбираться...

Читать дальше »

3 простых способа подружить KnockoutJs и SharePoint

2014-09-20T21:26:00.000+04:00

Попал на старый проект, SharePoint 2010. Бывает, что тут сделаешь! Спасаюсь от скуки только благодаря KnockoutJs :) Всвязи с чем - этот пост.

KnockoutJs как MVVM фреймворк на самом деле ничем не уступает тому же Angular'у. Единственная вещь, которую нужно очень хорошо изучить и вызубрить в Knockout - это когда скобки () нужны, а когда нет, и как этот ko observable wrapping вообще работает. Преодолев этот порог, больше с Knockout проблем не возникает. Angular конечно помощнее, более фундаментальный, но и всякой магии в нем намного больше, траблшутить крайне сложно, и модель освоения Angular действительно вот такая (проверено на собственном опыте):

Так что, в своих SharePoint-проектах я преимущественно использую именно Knockout. И в этом посте я опишу три простых техники использования Knockout совместно с SharePoint.

Читать дальше »

Поток мыслей: про косячников, внешний мир, и скрытую прелесть Apps

2014-08-29T21:42:00.002+04:00

Вот не понимаю, как можно в SharePoint'е кого-то называть косячниками? :)

Ошибка в SharePoint'е может возникнуть абсолютно в любом месте. В самом неожиданном! Самые безобидные действия могут повлечь за собой ужасающие последствия...
Читать дальше »

Введение в CSR

2014-03-20T09:00:00.000+04:00

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

CSR - это способ отображения данных в SharePoint 2013, пришедший на смену скоропостижно скончавшемуся XSLT. С помощью CSR отображаются и представления списков, и формы списков, и результаты поиска. Хотя бы поэтому нужно знать, что такое CSR и как он работает (о чем, собственно, я и намерен рассказать в этой статье).

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

Как устроен CSR

CSR - это подсистема отображения данных, главным отличием которой является тот факт, что она клиентская, т.е. реализована целиком на JavaScript. Иными словами, на стороне сервера рендерятся только данные в Json-формате, которые затем с помощью неких JavaScript-функций превращаются в HTML и затем этот HTML вставляется в DOM страницы.

Т.о. CSR представляет собой своеобразный конвертер, который принимает входящие данные, и возвращает HTML-строку на основе этих данных.

Для удобства CSR реализован не в виде одной огромной функции, а в виде множества javascript-функций, каждая из которых рендерит свой собственный кусочек HTML. Эти функции как правило вызывают одна другую, и таким образом как бы вложены друг в друга.

Исследовав исходный код CSR в файле /_layouts/15/clienttemplates.debug.js, я составил полную схему, которая демонстрирует порядок вызова этих функций:

OnPrePrender и OnPostRender отличаются от Render*-функций тем, что являются событиями, срабатывающими соответственно перед процессом генерации HTML и сразу после завершения этого процесса. Эти события служат в основном для расширений, в то время как Render*-функции выполняют основную работу по отображению.

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

Ну что же, пока что довольно просто и логично, неправда ли?

Используем CSR API

Есть два основных способа кастомизации CSR:

Подписывание на события OnPreRender и OnPostRender
Подмена (override) функций-шаблонов Render*.

Технически оба способа доступны через единое API, а именно через функцию

SPClientTemplates.TemplateManager.RegisterTemplateOverrides(options)

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

OnPreRender
Templates

View
Header
Body
Footer
Group
Item
Field

OnPostRender

В полях OnPreRender и OnPostRender можно указать одну функцию или же массив функций. Пример:

SPClientTemplates.TemplateManager.RegisterTemplateOverrides({
  OnPreRender: function() { console.log('CSR OnPreRender'); },
  OnPostRender: [
    function() { console.log('CSR OnPostRender'); },
    function() { alert('CSR OnPostRender'); }
  ]
});

Для полей внутри составного поля Templates можно указывать функцию или строку. В случае строки внутри можно использовать токены, ссылающиеся на JavaScript-контекст:

SPClientTemplates.TemplateManager.RegisterTemplateOverrides({
  Templates: {
    Footer: "Hello world from <#= ctx.ListTitle #>!"
  }
});

Результат работы такой функции будет следующий:

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

Вместо строки-шаблона можно использовать функцию, вот как это выглядит:

SPClientTemplates.TemplateManager.RegisterTemplateOverrides({
  Templates: {
    Footer: function(ctx) {
      return "Hello world from " + ctx.ListTitle + "!";
    }
  }
});

При генерации HTML-строк в CSR очень удобно использовать функцию String.format, которая автоматически уже есть на любой странице SharePoint'а и позволяет делать то же самое, что серверный C#-овский String.Format.

SPClientTemplates.TemplateManager.RegisterTemplateOverrides({
  Templates: {
    Footer: function(ctx) {
      return String.format("Hello world from {0}!", ctx.ListTitle);
    }
  }
});

Обратите внимание, что обработчик должен принимать в качестве параметра объект ctx - это тот самый JSON-объект, который генерируется на стороне сервера. И естественно, возвращает функция обработчика HTML-строку.

Замечание: при регистрации override'а, исходный шаблон будет ЗАМЕНЕН, т.е. больше он вызываться не будет, а вместо него будет запускаться ваш шаблон. Поэтому, если в предыдущем примере заменить Footer на Body, то результат будет такой:

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

Чтобы этого избежать, можно попробовать вместо замены шаблона использовать событие OnPostRender, и заменять/дополнять нужный вам элемент с помощью jQuery или селекторов.

Вызов других шаблонов

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

Оказывается, когда JSON-объект сгенерированный на стороне сервера начинает использоваться в качестве контекстного объекта в CSR, этот объект дополняется всякими полезными при обработке полями и методами. И в частности, в нем можно найти все Render*-функции:

Таким образом, вызов низлежащих функций не представляет никаких проблем. Пример:

SPClientTemplates.TemplateManager.RegisterTemplateOverrides({
  Templates: {
    View: function(ctx) {
      return ctx.RenderHeader() + ctx.RenderBody() + ctx.RenderFooter();
    }
  }
});

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

Куда же нужно положить JavaScript-код с вызовом RegisterTemplateOverrides, чтобы кастомизация заработала? Очень просто: нужно положить этот код на страницу сразу после представления списка.

Представленный выше пример я сделал следующим образом: перешел в режим редактирования страницы, добавил веб-часть Script Editor, и добавил туда вышеозначенный код:

Чтобы код работал из любого места страницы, необходимо обернуть его в широко известный SP.SOD.executeFunc:

SP.SOD.executeFunc("clienttemplates.js", "SPClientTemplates", function() {

  SPClientTemplates.TemplateManager.RegisterTemplateOverrides({
    // ...
  });

});

В этом случае можно подключать хоть в header, и делать это любым способом (через masterpage, через page layout, через script link и т.п.) - все сработает нормально.

Теперь давайте посмотрим, как сделать так, чтобы кастомизировался только нужный нам view (если на странице несколько view разных списков). Для этого в объекте опций предусмотрены 3 дополнительных поля: ViewStyle, ListTemplateType и BaseViewID.

ListTemplateType - номер шаблона списка (перечисление ListTemplateType). Например, для того, чтобы наш шаблон срабатывал только на списки типа "Задачи" ("Tasks"), нужно указать ListTemplateType=171:
```
SPClientTemplates.TemplateManager.RegisterTemplateOverrides({
  Templates: {
    Footer: function(ctx) {
      return String.format("Hello world from {0}!", ctx.ListTitle);
    }
  },
  ListTemplateType: 171
});
```
ViewStyle - тип представления. Имеет смысл указывать один из существующих типов представления, который можно задать в настройках любого представления списка в SharePoint:

ID для этих ViewStyle можно легко выдрать из того самого select'а на странице настроек представления:
BaseViewID - это значение свойства BaseViewID у View, его можно подсмотреть в PowerShell или в SharePoint Designer.

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

Про JSLink

Я с удивлением замечаю, что JSLink для многих является практически синонимом CSR. Многие статьи про CSR имеют заголовок из серии "Новая фича шарепойнта - JSLink", и дальше повествование идет о CSR... Я считаю своим долгом рассеять эти заблуждения.

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

JSLink - это просто способ прицепить некий javascript к некоему объекту SharePoint. Свойство JSLink присутствует у многих объектов SharePoint:

SPContentType
SPField
SPForm (кстати, по непонятным причинам, мне не удалось заставить работать именно SPForm.JSLink, хотя согласно моим исследованиям через dotPeek, все должно прекрасно работать - не знаю в чем было дело, может быть у вас получится?...)
SPView
XsltListViewWebPart
ListFormWebPart
...

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

Фактически эти js-файлы добавляются через контрол ScriptLink, что кстати говоря гарантирует автоматическое решение проблемы дубликатов - если кто не знал, контрол ScriptLink не позволяет загрузить на страницу дважды файл с одинаковым путем. Т.е. если поместить 2 ScriptLink-контрола на одну страницу и в обоих прописать один и тот же файл, то будет загружен лишь один файл (но сильно не обольщайтесь, дубликаты отслеживаются только по url, а не по контенту).

Внутри свойства JSLink можно использовать некоторые токены и особый синтаксис:

Во-первых, можно загружать несколько файлов сразу, используя в качестве разделителя вертикальную черту ("|").
Во-вторых, можно использовать токены "~site" и "~sitecollection", которые будут заменены на соответствующие URL.
В-третьих, можно использовать "(d)" на конце, чтобы грузить файлы в режиме SOD (Script-On-Demand). Т.е. вместо того, чтобы быть загруженным на страницу сразу, скрипт будет зарегистрирован в SOD системе и будет действительно загружен только в том случае, если кто-то к нему обратиться, используя "SP.SOD.executeFunc" или подобный метод. Внимание! Только скрипты, поддерживающие SOD, могут быть загружены таким способом.

В общем, JSLink - это очень удобный способ загрузки скриптов в SharePoint'е, и безусловно этот способ можно и нужно использовать вместе с CSR. Однако, важно понимать, что JSLink никак не влияет на CSR, и например можно подцепить CSR-скрипт к объекту списка А, и этим скриптом применять кастомизации к совершенно другому списку В....

Также, надеюсь понятно, что через CSR можно грузить далеко не только CSR-скрипты, но и любые сторонние файлы - например, jQuery, knockout.js и т.п.

Заключение

На мой взгляд CSR - это отличная замена XSLT. Огромным преимуществом CSR является то, что CSR базируется на JavaScript. Сейчас столько всего происходит вокруг JavaScript! Буквально каждую неделю появляются какие-нибудь новые классные библиотеки и фреймворки, создаются инструменты, и т.д. Мне кажется, CSR - это отличный шанс привнести современные достижения web-технологий в SharePoint, и начать создавать по-настоящему удобные и качественные решения.

Конечно, как и везде в SharePoint, у CSR есть свои тараканы, и следует быть крайне осторожными в оценке трудозатрат, особенно если вы пока еще мало работали с CSR.

Web scraping с помощью XmlWebPart

2014-03-19T09:00:00.000+04:00

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

На всякий случай, Web scraping - это способ интеграции с внешним ресурсом, при котором нужная информация выпарзивается прямо из HTML-кода некой внешней страницы в интернете. Обычно такое требуется, когда внешний сайт не предоставляет нормального API и нет никакой возможности его сделать (на самом деле, по моему опыту, такие ситуации возникают постоянно).

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

Читать дальше »

Отображение подчиненных списков в SharePoint

2014-03-16T09:00:00.000+04:00

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

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

С технической точки зрения, в этой статье я продемонстрирую использование OOTB веб-частей и их связывание друг с другом и с внешними параметрами. Также в процессе создания решения я буду использовать CSR и даже кастомизировать JSGrid.

Варианты решения

Как известно, в InfoPath специально для отображения подчиненных списков уже есть готовый инструмент, и вроде бы чего тут вообще изобретать велосипед!? Однако, с InfoPath обычно возникает слишком много проблем (подробнее можно почитать в моей статье про формы списков в SharePoint 2013), да и вообще InfoPath уже официально "заканчивается", если вдруг кто не в курсе. Но если не InfoPath, то что?

На самом деле задача решается достаточно легко средствами SharePoint, без всяких InfoPath и даже без кода. И вариантов решения даже не один, а довольно много. Например, в некоторых случаях можно использовать Document Set'ы, а Стас Выщепан придумал, что можно банально сделать библиотеку с оформленными по шаблону Excel-документами.

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

Создается отдельный page layout.
Создается отдельный список "позиций", с lookup-полем, ссылающимся на библиотеку документов настроенную на упомянутый выше page layout.
На page layout добавляются поля заказа, а также вебчасть CQWP, ссылающаяся на список позиций, с фильтром по вышеупомянутому lookup-полю.

Даже в изначальном виде этот способ отлично работает, хорошо интегрирован в SharePoint, визуален, пригоден для печати (ну, возможно придется добавить пару стилей CSS для @media print).

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

По шагам

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

Поехали:

Site Settings -> Master pages and page layouts -> Ribbon -> New document -> Page layout
Создаем тип содержимого. Используем ссылку "Create new content type"; выбираем Parent Content Type = Article Page (из группы Page Layout Content Types), задаем имя, OK.
Далее нужно скрыть ненужные поля и добавить те поля, которые вам нужны. Будьте аккуратны с такими полями как например поля типов Publishing HTML и Publishing Image. Они обязательно должны добавляться именно на этом шаге, т.е. через Content Type, а не непосредственно в библиотеку документов, иначе возможны проблемы.
Как только тип содержимого создан, возвращаемся к созданию Page layout, обновляем список типов содержимого, выбираем только что созданный, выбираем название для Page layout, OK -> page layout создан!
Создаем отдельный publishing сайт
Конфигурируем этот сайт на использование вновь созданного page layout'а (Site settings -> Page layouts and site templates -> Page layouts -> Pages in this site can only use the following layouts -> выбираем только наш layout):
Также выставляем page layout по умолчанию в то же значение, и сохраняем настройки.
Теперь создаем список товаров и список позиций на этом самом отдельном сайте. Надеюсь понятно, почему списка 2:

список товаров включает в себя все возможные товары
список позиций содержит ссылки на те товары, которые были выбраны пользователем в заказ. Т.е. по сути дела список позиций это агрегированная таблица, реализующая связь много-ко-многим, и включающая в минимальном варианте 2 колонки: товар и заказ. Чаще всего там также будут дополнительные данные: например, из таблицы товаров может быть подтянута картинка товара, а также не помешает поле с количеством товаров для заказа. Также логично для списка позиций выбрать настройку "отображать только созданные мной записи", и добавить группировку по заказу. Наконец, не забудьте пожалуйста поле Title скрыть (через тип содержимого), и плюс сделать его не обязательным (в настройках поля).

Списки созданы - давайте займемся донастройкой page layout'а. Открываем SharePoint Designer, переходим на нашу коллекцию сайтов, Files->_catalogs->masterpage-> ищем вновь созданный page layout, и выбираем Edit file in Advanced Mode через контекстное меню.
Добавляем обычные поля из типа содержимого. Это кстати можно сделать через SharePoint Designer UI: на Ribbon, есть вкладка Insert, и там эти поля можно найти в раскрывающейся кнопке "SharePoint" - правда иногда приходится немного подождать, т.к. список полей загружается какое-то время, и доступен не сразу.
Далее добавляем собственно самую интересную часть: список позиций. Тут есть два варианта реализации:

Наиболее простой способ это сделать - это использовать CQWP (Content by Query WebPart), как я упоминал выше. Эта веб-часть не имеет возможности редактирования, но зато списки товаров и позиций могут располагаться на любом сайте в текущей сайт-коллекции, что очень удобно.
Чтобы сделать более user-friendly интерфейс и обеспечить редактирование "на лету", можно использовать XLV (XsltListViewWebPart). В этом случае списки товаров и позиций должны располагаться на том же сайте, где расположена библиотека документов, настроенная на использование нашего page layout'а. Этот вариант технически сложнее (но и интереснее).

Список позиций через Content Query Web Part

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

На любой webpart page временно добавляем CQWP. Например можно добавить на форму создания элемента любого списка
Настраиваем CQWP на список позиций.
Добавляем фильтр по полю из списка позиций, которое указывает на заказ (например, у меня это поле называется Order). Обычно я делаю так, что lookup-поле "Order" ссылается на Title страницы, но в настройках этого поля отмечаю также колонку ID (при этом автоматически добавляется Dependent lookup поле "Order:ID"):

И тогда фильтр нужно применять уже именно на поле "Order:ID". В качестве значения фильтра необходимо указать строку "[PageFieldValue:ID]".
При необходимости изменения способа отображения списка, добавляем стиль в ItemStyle.xsl, и соответственным образом меняем настройки CQWP.
Подсматриваем markup получившейся CQWP из SharePoint Designer, и copy+paste этот маркап в page layout. Обычно нужно скопировать тег WpNs0:ContentByQueryWebPart и регистрацию соответствующего префикса, т.е. код <%@ Register TagPrefix="WpNs0" ... %>.
Для упрощения редактирования, просто добавьте ссылку (target="_blank") на список перед этой вебчастью, обернув ее в EditModePanel. Практика показывает, что клиенты в большинстве случаев вполне спокойно относятся к такому варианту редактирования, особенно если функционал редактирования доступен ограниченному числу лиц.

Список позиций через Xslt List View Web Part

Для реализации этого варианта потребуется немного больше знаний и немного больше ручных действий:

Во-первых, перейдите в SharePoint Designer, на отдельный сайт который вы создали, и найдите файл Lists/ваш_список/AllItems.aspx. Перейдите к редактированию этого файла и выкопируйте оттуда тег XsltListViewWebPart, а также соответствующий ему серверный Register-тег для TagPrefix="WebPartPages". Скопированную разметку добавьте на page layout.
Если сейчас вы посмотрите, как выглядит страница созданная на основе нашего page layout'а, там вы увидите представление списка. Наша задача сделать так, чтобы в режиме редактирования XLV автоматически переходил в режим Quick Edit, а в режиме просмотра выглядел примерно как CQWP. Это делается довольно просто.
Сначала добавьте код для режима редактирования (нужный код я банально вытащил из onclick атрибута стандартной ссылки "edit this list"):
```
<PublishingWebControls:EditModePanel runat="server">
    <script type="text/javascript">
        _spBodyOnLoadFunctions.push(function()
        {
            EnsureScriptParams('inplview', 'InitGridFromView', '{YOUR-GUID-HERE}');
        });
    </script>
</PublishingWebControls:EditModePanel>
```
Этот код необходимо поместить сразу после XsltListViewWebPart. GUID берется из View Name:

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

<PublishingWebControls:EditModePanel runat="server" PageDisplayMode="Display" SupressTag="True">
    <script type="text/javascript">
       SP.SOD.executeFunc('clienttemplates.js', 'SPClientTemplates.TemplateManager', function() {
            SPClientTemplates.TemplateManager.RegisterTemplateOverrides({
                Templates: {
                    View: function (ctx) {
                        return String.format('<div class="cbq-layout-main"><ul class="dfwp-list dfwp-column">{0}</ul></div>', ctx.RenderBody(ctx)); 
                    },
                    Item: function (ctx) {
                        return String.format('<li class="dfwp-item"><div class="item"><div class="link-item">{0}</div></div></li>', ctx.CurrentItem["Item"][0].lookupValue);
                    }
                }
            })
       })
    </script>
</PublishingWebControls:EditModePanel>

Теперь необходимо добавить фильтр по полю Order. Для этого, нужно сделать следующее:
- сначала нужно добавить в page layout контрол NumberField, ссылающийся на ID текущей страницы, который не будет отображаться, но значение из которого мы будем через ParameterBinding передавать в XLV:
```
<div style="display:none;">
   <SharePointWebControls:NumberField ID="PageID" ControlMode="Display" FieldName="1d22ea11-1e32-424e-89ab-9fedbadb6ce1" runat="server"/>
</div>
```
- Теперь добавляем ParameterBinding (рядом с уже существующими биндингами внутри тега XsltListViewWebPart):
```
  <ParameterBinding Name="pageId" Location="Control(PageId,ItemFieldValue)" />
```
- И наконец, собственно настраиваем фильтр, добавляя в тег Query (внутри View) следующий код:
```
<Where><Eq><FieldRef Name="Order" LookupId="TRUE" /><Value Type="Integer">{pageId}</Value></Eq></Where>
```

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

Вроде бы уже здорово, вау, но... на самом деле ничего не работает :)

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

Кроме такой вот большой проблемы, есть также и несколько мелких недочетов:

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

Поскольку XLV в режиме редактирования выводится с помощью JSGrid, для исправления этих проблем понадобятся знания по контролу JSGrid. К сожалению, документации по JSGrid в интернете практически нет, а API там очень большой и разобраться самостоятельно - сложно. Но если все-таки это сделать, все наши проблемы решаются буквально парой десятков строк javascript-кода (этот фрагмент необходимо разместить после XLV):

<PublishingWebControls:EditModePanel runat="server">
    <script type="text/javascript">
        _spBodyOnLoadFunctions.push(function()
        {
            var viewId = '{8571F3CD-C286-4D4D-89AD-D4B2507A9448}';
            var orderColumnName = 'Order';

            g_SPGridInitInfo[viewId].jsInitObj.canUserAddColumn = false;
            g_SPGridInitInfo[viewId].jsInitObj.showAddColumn = false;
            EnsureScriptParams('inplview', 'InitGridFromView', viewId);
            
            SP.SOD.executeFunc('spgantt.js', 'SP.GanttControl', function() {
                var jsGridContainer = $get("spgridcontainer_" + g_SPGridInitInfo[viewId].jsInitObj.qualifier);
                jsGridContainer.jsgrid.HideColumn(orderColumnName);
                var columns = jsGridContainer.jsgrid.GetColumns();
                for (var i in columns)
                {
                    columns[i].isSortable = false;
                    columns[i].isAutoFilterable = false;
                }
                jsGridContainer.jsgrid.UpdateColumns(new SP.JsGrid.ColumnInfoCollection(columns));
                jsGridContainer.jsgrid.AttachEvent(SP.JsGrid.EventType.OnEntryRecordPropertyChanged, function(args) {
                    if (args.fieldKey != orderColumnName)
                    {
                        var update = SP.JsGrid.CreateUnvalidatedPropertyUpdate(args.recordKey,orderColumnName,currentPageId,false);
                        setTimeout(function() {jsGridContainer.jsgrid.UpdateProperties([update], SP.JsGrid.UserAction.UserEdit);}, 100);
                    }
                });
            });
        });
    </script>
</PublishingWebControls:EditModePanel>

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

Отмечу лишь, что для того, чтобы все заработало, вам необходимо будет добавить в представление списка колонку "Order". Как можно заметить выше, приведенный код ее скрывает от пользователя, и заполняет значением currentPageId каждый раз, когда добавляется новая строка. Переменную currentPageId я получил, используя следующий фрагмент кода, добавленный перед тегом со скриптом:

<script type="text/javascript">
    var currentPageId = <SharePointWebControls:NumberField ControlMode="Display" FieldName="1d22ea11-1e32-424e-89ab-9fedbadb6ce1" runat="server"/>;
</script>

Результат:

Полный код фрагмента, который получился у меня для XLV, я выложил на pastebin: http://pastebin.com/3TJCcc8f

Заключение

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

Однако, необходимо понимать, что даже несмотря все это, множество ограничений и ~~багов~~подводных камней приводят к тому, что очень сложно рассчитать заранее трудозатраты на создание подобных решений и гарантировать их полную работоспособность. Нередко получается, что 90% решения готово за час, а оставшиеся 10% делаются 2-3 дня. В таких случаях важно не буксовать в одном месте, а придумывать и пробовать разные альтернативные варианты - в шарепойнте их всегда очень много.

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

CamlJs 2.0

2013-08-26T11:29:00.000+04:00

В предыдущем посте я писал немного о том, как мне удалось улучшить условия разработки CamlJs: про внутренний переход на TypeScript, введение юнит-тестов и визуального diff'а. Благодаря этим внутренним усовершенствованиям, мне удалось быстро привести проект в порядок, добавить в него существенные улучшения и выпустить релиз 2.0, который выходит сегодня, ура! :)

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

Зачем нужен CamlJs

Итак, проект CamlJs позволяет формировать строку Caml Query на стороне клиента (в JavaScript) для использования совместно с SP.CamlQuery или SPServices. CamlJs привносит следующие основные преимущества перед использованием просто строк с XML:

Читаемость. Захардкоженный XML в коде выглядит жутковато и громоздко, запросы написанные на CamlJs читать намного проще и они гораздо компактнее.
Защита от опечаток. XML - это по сути "magic string", в котором очень легко сделать опечатку. SharePoint в этом случае возвращает, как водится, совершенно безумные, вводящие в заблуждение сообщения об ошибках. Чтобы понять, что на самом деле ты где-то просто забыл закрывающую кавычку или что-то в этом духе, приходится тратить кучу времени...
Intellisense. CamlJs дает intellisense и inline подсказки, благодаря чему даже люди, не в совершенстве знающие CAML Query, могут составлять сложные запросы без ошибок.
Обработка SharePoint-овских "багофич". Например, многие ли из вас знают, что при попытке применить условие <Includes> для MultiLookup полей указывающих на поле типа DateTime SharePoint вернет ошибку? :) А CamlJs знает это - и еще кучу тонкостей, которые я собрал за долгие годы работы с CAML Query...

Что нового в версии 2.0

Версия 2.0 существенно улучшена по сравнению с 1.0. При этом, синтаксически версии оставлены максимально совместимыми.

Поддержка скобочных выражений и генерации частей запросов. CamlJs 1.0 не поддерживал возможности создания скобочных выражений. Все операции в запросах генерились строго в порядке справа налево, и более-менее сложную логику с множеством вложенных Or и And реализовать было, к сожалению, невозможно :( Теперь это исправлено за счет введения операторов All и Any.
Значительно улучшен Intellisense. Теперь набор возможных сравнений для поля зависит от типа этого поля, т.е. например к полям Integer нельзя применить сравнение Contains и т.д.
Изменена обработка Lookup-полей. Теперь элемент LookupField поддерживает методы Id() и ValueAs<type>(), которые уже в свою очередь возвращают корректный набор операций. Например, если у вас есть Lookup-поле "City", которое ссылается на текстовое поле "Title" в таблице "Cities", то чтобы получить все записи у которых город начинается на "М", надо использовать запрос LookupField("City").ValueAsText().BeginsWith("M").
Улучшен элемент UserField. Помимо изменений связанных с изменениями Lookup-полей (а User-поле это как известно частный случай Lookup-а), функционал элемента Membership теперь реализуется несколькими функциями элемента UserField. Кроме того, для удобства, была добавлен метод "EqualToCurrentUser()", который функционально эквивалентен конструкции "EqualTo(CamlBuilder.CamlValues.UserId)".
Улучшен элемент DateRangesOverlap. К сожалению, выяснилось что этот элемент невозможно использовать вместе с SP.CamlQuery, поскольку CSOM игнорирует тэг QueryOptions, а для DateRangesOverlap нужно задавать QueryOptions/CalendarDate и QueryOptions/ExpandRecurrence. Однако, остается возможность использовать DateRangesOverlap хотя бы вместе с SPServices.
Добавлен новый элемент BooleanField для полей типа Boolean.
Добавлен новый элемент UrlField для полей типа URL.
DateField и DateTimeField теперь конвертируют дату (Date) к правильному формату.

Также, проект теперь написан на TypeScript и покрыт юнит-тестами, благодаря чему можно гарантировать повышенные стабильность и правильность работы.

Наконец, проект теперь доступен через Nuget (добавляет camljs.js в папку Scripts вашего проекта):


PM> Install-Package CamlJs

Определения для TypeScript также доступны через Nuget:


PM> Install-Package camljs.TypeScript.DefinitelyTyped

Миграция с версии 1.0 на 2.0

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

Также, обратите пожалуйста внимание на то, что элементы Membership и LookupIdField теперь помечены как "deprecated" и будут убраны в следующем большом релизе. Рекомендуется переписать запросы с их использованием на эквивалентные конструкции LookupField("...").Id() и UserField("...").IsInCurrentUserGroups() и т.д.

Заключение

В SharePoint 2013 роль JavaScript неимоверно возросла. Появилась необходимость создания комплексных JavaScript-решений, работающих полностью на стороне клиента. В этих условиях, приобретают повышенное значение всевозможные инструменты и расширения для клиентских операций, в том числе и разрабатываемый мною opensource-проект CamlJs.

Надеюсь, CamlJs поможет вам улучшить ваши JavaScript-решения и упростить реализацию задач, связанных с генерацией сложных запросов к спискам. Удачи!

Про TypeScript и Unit-test'ы

2013-08-19T09:30:00.000+04:00

Недавно для своего opensource-проекта CamlJs.codeplex.com (aka SharePoint EcmaScript Caml Builder) потребовалось написать юнит-тесты. При этом раскопал несколько приятных полезностей, которыми собственно и хочу поделиться в этой статье.

CamlJs

На всякий случай, для тех кто возможно не в курсе, суть этого проекта - удобное формирование XML Caml-запросов для SP.CamlQuery и/или для SPServices, с интеллисенсом и подсказками. Выглядит это примерно так:

Особенность проекта в том, что он действительно не только бережет от опечаток, но практически основной целью при создании CamlJS являлось создание качественного интеллисенса и подсказок, чтобы не требовалось быть экспертом в Caml Query чтобы написать средний запрос.

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

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

tsUnit

Простенький движок для юнит-тестов на TypeScript существует - это tsUnit. Пользоваться примерно так: наследуемся от класса tsUnit.TestClass, используем методы класса-родителя для assert'ов, и плюс потребуется простенький код инициализации.

Пример использования (с сайта проекта):

/// <reference path="tsUnit.ts" />
/// <reference path="Calculations.ts" />

class SimpleMathTests extends tsUnit.TestClass {

    private target = new Calculations.SimpleMath();

    addTwoNumbersWith1And2Expect3() {
        var result = this.target.addTwoNumbers(1, 2);

        this.areIdentical(3, result);
    }

    addTwoNumbersWith3And2Expect5() {
        var result = this.target.addTwoNumbers(3, 2);

        this.areIdentical(4, result); // Deliberate error
    }
}

// new instance of tsUnit
var test = new tsUnit.Test();

// add your test class (you can call this multiple times)
test.addTestClass(new CalculationsTests.SimpleMathTests());

// Use the built in results display
test.showResults(document.getElementById('results'), test.run());

Неудобства

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

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

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

Идеальным решением в этом случае была бы, безусловно, подсветка отличий (diff).

Давайте рассмотрим, как я решил эти проблемы.

Сравнение форматированного и неформатированного XML в JavaScript

После нескольких попыток, я предпочел решить проблему хранения XML-простыней в коде тестов путем перегонки обоих кусков XML в объекты и затем в JSON через JSON.stringify и сравнения уже JSON-строк. Таким образом, я смогу хранить XML-фрагменты в коде тестов в форматированном виде, что улучшит читабельность кода.

Когда-то давно я писал про то, что в SharePoint есть встроенная функция для превращения XML-строки в dom element. Эта функция прекрасно работает, однако оказалось, что получившийся dom-объект нельзя сериализовать через JSON.stringify (вообще никакие dom-элементы через JSON.stringify не выводятся)! Готового решения этой проблемы я не нашел, но быстро написал простенькую функцию на основе фрагмента из интернетов, которая dom-элемент перегоняет в объект JavaScript. Функция эта выглядит следующим образом:

        function elementToObject(el) {
            var o = {};
            var i = 0;
            if (el.attributes) {
                for (i; i < el.attributes.length; i++) {
                    o[el.attributes[i].name] = el.attributes[i].value;
                }
            }

            var children = el.childNodes;
            if (children.length) {
                i = 0;
                for (i; i < children.length; i++) {
                    if (children[i].nodeName == '#text')
                        o['#text'] = children[i].nodeValue;
                    else
                        o[children[i].nodeName] = elementToObject(children[i]);
                }
            }
            return o;
        }

Дальше элементарно:

var domElement = CUI.NativeUtility.createXMLDocFromString("<root>" + xml + "</root>");
var obj = elementToObject(domElement);
return JSON.stringify(obj.root, undefined, 2);

В результате XML из скриншота выше преобразуется вот в такой кусок более ёмкого и читабельного JSON'а:

 {
   "Where":  {
     "And":  {
       "In":  {
         "FieldRef":  {
           "Name": "Category"  },
         "Values":  {
           "Value":  {
             "Type":  "Integer",
             "#text":  "10"
           }
         }
       },
       "Leq":  {
         "FieldRef":  {
           "Name":  "ExpirationDate"
         },
         "Value":  {
           "Type":  "Date",
           "Now":  {}
         }
       }
     }
   },
   "OrderBy":  {
     "FieldRef":  {
       "Name":  "ExpirationDate",
       "Ascending":  "False"
     }
   }
 }

Обратите внимание: неважно, что этот JSON не идеальный. Нет задачи сделать идеальный JSON, есть задача сравнить 2 XML'а.

Итоговый код моих юнит-тестов для проекта CamlJs (включая хелпер для реализации преобразования XML->Json) можно найти на Codeplex.

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

Визуальный Diff на JavaScript

На самом деле, тут всё банально, есть готовая библиотека, которая делает diff на js. Мне пришлось только немного пропатчить tsUnit, чтобы обеспечить интеграцию. В итоге получилась вот такая картинка:

Сразу видно, что происходит, удобно, работа ускорилась в разы.

Библиотека не идеальная и ищет отличия в словах (т.е. если у вас текст без пробелов, толку от неё мало). Лично мне хватило, т.к. я использую форматирование JSON и как следствие, везде где надо пробелы стоят. Однако есть более крутые библиотеки, и их довольно много. В частности, есть очень хорошая либа google-diff-match-patch от Neil Fraser, я на неё поздновато наткнулся, но алгоритм там более подходящий для моих целей, и библиотека сама очень развитая.

Выводы

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

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

С другой стороны, очень важно здесь не переусердствовать. Нельзя писать систему чтобы писать систему :) Есть простое решение проблемы - отлично, применяем быстро, и продолжаем работать над основным проектом. Быстро не получилось? Значит без этого "удобства" можно обойтись.

Так что, удобной разработки, и до скорых встреч!

XSLT мертв. R.I.P. Да здравствует CSR!

2013-08-16T09:20:00.000+04:00

Для тех, кто еще может быть не в теме - и я знаю, такие есть: XSLT в SharePoint 2013 был эффективно убит.

Да, конечно, мы всё также можем использовать веб-части с XSLT и почти всегда это будет работать. Но есть нюансы:

Изъят мощнейший инструмент для разработки XSLT - SharePoint Designer. Точнее, изъята та его часть, которая относилась к генерации XSLT. Кое-что можно по-прежнему выжать из местами оставшихся кнопок на Ribbon в Code View, но даже для простейших представлений код веб-частей генерируется нередко нерабочий. Иными словами, это уже неподдерживаемый функционал, которым пользоваться нереально.
XSLT-преобразования очевидно уже стоят в низком приоритете для команды тестирования SharePoint. Как следствие - уже сейчас, в SP2013, начинают накапливаться баги, связанные с работой XSLT. Пример: в js, который используется для свертывания/развертывания групп при наличии группировки в DataFormWebPart - в SP2013 содержит ошибку. Т.е. группировку в этой веб-части невозможно использовать "OOTB", придется этот баг исправлять подменяя SharePoint'овскую js-функцию. Я наткнулся на этот баг, когда пытался мигрировать свой английский блог, который у меня сделан на SharePoint 2010 :(
Представлен концептуально новый подход к отображению данных (Client Side Rendering ака CSR), и сейчас ни одна веб-часть в SharePoint по умолчанию более НЕ использует XSLT преобразования. Все списки показываются с помощью CSR, и результаты поиска - тоже.
CSR действительно лучше, и нет ни единой причины не предпочесть его старому подходу. Это JavaScript templating engine, пусть корявый, но всё-таки JS как язык является гораздо более мощным, более развитым и более современным средством разработки, чем XSLT. Под JavaScript, словно грибы, растут фреймворки, создаются метаязыки (coffee script, TypeScript, Script#, etc.), пишутся библиотеки, расширяются его возможности (html5) и т.д. и т.п. А когда вы слышали последний раз про усовершенствования в XSLT? :)

XSLT в SharePoint 2013 был эффективно убит. И это факт.

И если в SP2010 еще можно поработать с XSLT (но без излишнего рвения, не забывайте что могут возникнуть проблемы с миграцией), то если вы начинаете новый проект на SP2013, забудьте об XSLT. Начинайте учить CSR.

CSR сыроват и не без своих тараканов. Но он уже лучше XSLT. Многие вещи на CSR делаются в 3 раза быстрее, чем на XSLT, а еще есть вещи на XSLT вообще нельзя было сделать, а на CSR они делаются на раз-два-три.

В проекте SPTypeScript мы сделали на момент написания этой статьи уже 6 примеров по использованию CSR:

Разбиение формы на вкладки
Lookup-поле с автокомплитом, работающим по данным поиска
Кастомная валидация полей формы списка
"Color coding" на CSR
Custom Field на CSR (пример сделан на основе того что есть на MSDN, но внутри код гораздо более правильный и понятный)
Custom List View (очень простой пример из серии "как начать")

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

Также, совсем недавно я читал доклад про CSR - очень полезно для старта и освещены некоторые моменты, которых вы врядли где-то еще найдете (да, CSR как это принято в SharePoint'е, документирован процентов на 15% отсилы - а в интернетах еще пока информации маловато).

Подводя итог: на мой взгляд, будущее рендеринга данных в SharePoint - это что-нибудь типа CSR + TypeScript + KnockoutJs. А XSLT, он мертв. И несмотря на человекомесяцы в обнимку с ним и целую пачку статей про него в этом блоге, наверное это и к лучшему :)

Как я исправил невоспроизводимую ошибку SharePoint с помощью UX-паттерна

2013-08-05T09:00:00.000+04:00

В прошлый раз я теоретизировал о необходимости знаний по UX у SharePoint разработчиков. Сегодня хочется рассказать об интересном прецеденте использования UX-паттерна для исправления невоспроизводимой ошибки SharePoint.

Дано

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

Иногда один или несколько сайтов не создаются по неизвестной причине. Ошибка валится на Webs.Add и она плавающая: то есть, то нет. Более того, по закону подлости она возникает исключительно на production environment. И это еще не всё, когда ко мне попала эта задача, логи с последней ошибкой уже потерлись, поэтому я даже не располагал сообщением об ошибке!...

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

Стандартный подход

Стандартным подходом было бы поочередное исследование кода решения и затем кода Webs.Add через рефлектор, и попытка понять в чем может быть дело (скорее всего неудачная, т.к. Webs.Add довольно быстро уходит в Unmanaged код).

Можно конечно пробовать разные варианты параметров или порядка или какие-нибудь задержки... Но поскольку ошибка не воспроизводится нигде кроме production, а production можно обновлять только раз в 1-2 месяца, да еще и используется этот модуль не интенсивно... В общем методом "тыка" можно было бы растянуть проблему на годы. Собственно, это и происходило - когда я взялся за проблему, она существовала уже больше года.

UX подход

Давайте попробуем подойти к проблеме с точки зрения UX. Итак, есть некий интерфейс, пользователь заполняет некоторые поля, выбирает сколько создавать сайтов и т.п. В конце концов, он жмет на кнопку "Создать" - и сайты создаются ...или не создаются, как повезет. Интерфейс в том виде, в котором он попал ко мне, просто глотал все ошибки, всвязи с чем даже непонятно было, какой конкретно сайт не был создан. В результате пользователь шел и проверял, все ли сайты создались, и если нет - то досоздавал их вручную.

В моих любимых Apple UX Guidelines есть следующий пункт:

Display an informative, actionable alert message when something goes wrong. An alert should clearly convey what happened, why it happened, and the options for proceeding. Describe a workaround if one is available and do whatever you can to prevent the user from losing any data. Avoid using an alert to deliver information that the user can’t act upon.

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

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

Что это означает в нашем случае?

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

Решение

Решение очень простое, но при этом надежное и удобное.

Во-первых, я добавил информацию об ошибке: в случае, если один или несколько сайтов не были созданы, отображается таблица со статусом по каждому из сайтов (Success/Failure).

Во-вторых, рядом с Failure я добавил кнопку Retry. ВСЁ!

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

Такие улучшения интерфейса безусловно повлекли за собой некоторое количество работы и немного рефакторинга, т.к. для того, чтобы сделать возможность Retry, пришлось отделить код создания сайтов в обособленный метод, но в любом случае вся работа заняла 2 дня - с большими перерывами на чай и бильярд. Стоит ли говорить, что investigation мог бы занять практически сколько угодно времени и ни к чему не привести?

Отдельно отмечу: это решение полностью закрывает задачу. ПОЛНОСТЬЮ. С точки зрения пользователя, проблемы больше нет. Нажать пару раз кнопку Retry, при том что интерфейс используется пару раз в месяц - да это вообще не вопрос, верно же?

Выводы

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

Так что вот. И да пребудет с вами UX! :)

Usability и UX в SharePoint

2013-08-02T09:00:00.000+04:00

SharePoint далеко не идеален с точки зрения Usability, и это ни для кого ни секрет. Однако я заметил, что как ни странно, клиенты в большинстве случаев довольно спокойно относятся к "страшным", медленным и неудобным интерфейсам в интранете. Более того, когда я предлагаю даже незначительные UX-усовершенствования которые не занимают много времени на реализацию, клиенты склонны отказываться...

Клиенты нормально относятся к страшным и неудобным интерфейсам

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

Читать дальше »

Доклад Client Side Rendering

2013-07-10T09:11:00.002+04:00

Вчера в костромском офисе Софтлайн прочитал доклад о Client Side Rendering.

Рабочие процессы SharePoint 2013: Workflow Services API в примерах

2013-06-13T09:00:00.000+04:00

В предыдущем посте я очень кратко (но ёмко) прошелся по Workflow в SharePoint 2013. Сегодня хочу продолжить тему и рассказать о новом клиентском API под названием Workflow Services (и показать, как его можно использовать), которое доступно в том числе из SharePoint JavaScript Object Model.

Читать дальше »

Рабочие процессы SharePoint 2013

2013-06-12T09:00:00.000+04:00

В SharePoint 2013 в части рабочих процессов (Workflow) произошли довольно важные перемены - как вы все наверное уже знаете. Постараюсь обобщить в цельную картину, кратко и без маркетингового трепа:

Самое главное: SharePoint 2013 поддерживает теперь два типа Workflow: старыe (WF3) и новые (WF4). Старые крутятся внутри SharePoint как и раньше, а новые хостятся вне SharePoint, в отдельном компоненте под названием Workflow Manager. Чтобы обеспечить работоспособность новой связки, появилось Workflow Service Application, а для непосредственного взаимодействия WF с SharePoint используется механизм Apps.
В новых Workflow есть циклы, переходы, вызов web-сервисов и других Workflow (что круто), но зато напрочь отсутствует куча жизненно важных Workflow Actions, таких как например "Set Approval Status" и некоторых других.
Reusable Workflow в режиме WF2013 теперь нельзя цеплять к Content Type и нельзя их публиковать на всю коллекцию сайтов (кнопка "Publish Globally" задисейблена). Так что готовьтесь к копипасту :)
Impersonation Step в новых заменен на "App Step" (подробнее на MSDN). Для повышения привилегий используется тот же механизм, что в Apps.
Есть interop - т.е. из новых можно вызывать старые WF. В итоге в реальных проектах вполне ожидаем следующий сценарий: основной РП пишется на WF4, а из него по мере необходимости вызываются WF3-workflow. Напоминает забивание гвоздей микроскопом, но тут уж куда деваться :)
OOTB-Workflow, такие как Approval, Collect Feedback и т.д. - могут выполняться только в режиме совместимости, т.е. в режиме WF3.
Custom Workflow Actions теперь декларативные: они представляют собой XOML-файлы, в которых можно использовать только ограниченный набор Workflow Activities.
Custom Workflow (Code) Activity создавать всё-таки можно, хотя и ~~через жопу~~ сложно (т.е. в O365 уж точно так сделать не получится). Альтернативно предлагается писать веб-сервисы и вызывать веб-сервисы из Workflow. А что, вариант :)
Для новых РП теперь есть очень мощное клиентское API (см. мой следующий пост про Workflow Services API).
В SPD теперь есть новый Workflow Editor (только при наличии Visio на компьютере).
Обладатели SharePoint Foundation остались без Workflow Manager и как следствие без WF нового типа.

Честно сказать, впечатления от нововведений неоднозначные. Для меня самый неприятный момент - это отсутствие некоторых фундаментальных WF activities в РП нового типа. Впрочем, уже есть мысли, как это можно "логически" обойти :)

P.S. Если у кого есть что добавить к моему списку, отпишитесь плиз в комменты!

Update 13.06: добавил уточнение про Impersonation Step и App Step, невозможность публиковать новые РП на всю коллекцию узлов, и ссылку на новый пост про Workflow Services.

Custom Workflow Action: Количество рабочих дней между датами

2013-04-29T09:10:00.000+04:00

Многие недооценивают/недолюбливают SPD Workflows - это рабочие процессы, которые создаются в SharePoint Designer. Обычный аргумент заключается в том, что они недостаточно гибкие и много чего не позволяют, в то время как де Visual Studio Workflows - это C#, и там уж все можно. Ну-ну :)

На самом деле SharePoint Designer Workflows - очень даже гибкие. Во многом - благодаря возможности создания для них программных Custom Actions, причем эти Custom Actions можно создавать даже для Sandbox, и следовательно - использовать в O365. Ниже я покажу, как это сделать, на реальном примере.

Проблема вычисления количества рабочих дней между датами

Проблема это известная и не новая. С помощью вычисляемого поля (Calculated Field) можно легко вычислить количество календарных дней между датами, и после некоторых ковыряний даже можно исключить субботу и воскресенье - но как быть с праздниками!? Праздники нередко переносятся туда-сюда, т.е. каждый год решение о распределении праздников принимается нашим правительством, так что предугадать/рассчитать это распределение попросту невозможно: сегодня так решили, а завтра начинают январские праздники на май переносить и т.д. :)

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

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

Почему Custom Workflow Action?

Workflow заточены для построения бизнес-процессов. Именно в бизнес-процессах требуется знать разницу в рабочих днях чаще всего. Например, для рассылки напоминаний исполнителям "за 3 рабочих дня" до истечения срока рассмотрения заявки и т.п.

Как я уже упоминал в своем вводном посте про Workflow, рабочие процессы нужно использовать, когда требуется организовать бизнес-процесс, т.е. взаимодействие системы с людьми, особенно если участников вовлечено в процесс много. Если процесса никакого нет - лучше использовать Event Receiver'ы и Timer Job'ы. Повально использовать WF - идея дурная.

Workflow Action XML

Самая интересная часть написания Workflow Action - это создание т.н. "Workflow Action Statement", т.е. определение, как будет внешне выглядеть сконструированный вами шаг процесса.

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

<RuleDesigner Sentence="Count holidays between %1 and %2 (result to %3)">

Дальше, как можно догадаться, нужно задать настройки для параметров, определенных через плейсхолдеры %1, %2 и %3. Это делается вложенными элементами FieldBind:

<RuleDesigner Sentence="Count holidays between %1 and %2 (result to %3)">
    <FieldBind Field="startDate"
               Text="start date" Id="1"
               DesignerType="Date" />
    <FieldBind Field="endDate"
               Text="end date" Id="2"
               DesignerType="Date" />
    <FieldBind Field="Result"
               Text="HolidaysCount" Id="3"
               DesignerType="ParameterNames" />
</RuleDesigner>

Как нетрудно догадаться, атрибут Id задает номер плейсхолдера, атрибут Text задает, какой текст будет отображаться вместо соответствующего плейсхолдера по умолчанию (когда еще не выбрано конкретное значение), а Field - это внутренний идентификатор поля, который потребуется немного позже. Таким образом, в SharePoint Designer заданный таким образом Custom Workflow Action будет выглядеть следующим образом:

По-моему, здорово! :)

Безусловно, самый интересный атрибут элемента FieldBind - это DesignerType. Например, значение "Date" для этого атрибута задает вот такой дизайнер для элемента:

Обратите внимание: рядом с полем ввода две кнопки! Одна ([...]) вызывает обозначенный на скриншоте диалог ввода "фиксированного значения" даты/времени. Другая же ([fx]) вызывает стандартный Lookup-диалог, который позволяет вставить значения поля, переменной, параметра и т.п.:

Существует, конечно же, множество других типов дизайнеров, которые можно использовать. Есть среди них дизайнеры для разных типов значений - Bool, Integer, Float, Hyperlink и др., есть преднастроенные выпадающие списки: выбор одного из полей текущего списка, выбор одного из списков текущего узла, и т.д., есть выпадающие списки для которых можно задать список значений, а есть даже возможность затянуть список значений из внешнего датасорса (мне правда еще ни разу такое не требовалось). В общем, вариантов масса.

Все комбинации можно посмотреть в файле 14\TEMPLATE\XML\WorkflowActions.xsd. Довольно доходчивое описание, что каждый из этих дизайнеров собой представляет (правда, без скриншотов), можно найти на MSDN.

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

На самом деле, возможно даже не все об этом знают, но любой элемент SPD Workflow имеет не только "визуальное" представление в виде конструктора, но также представление в виде PropertyGrid, которое вызывается через пункт контекстного меню "Properties":

В этом представлении может иногда оказаться больше свойств, чем полей в конструкторе шага. Эти свойства также задаются через XML, элементами Parameter, и упомянутый атрибут Field элемента FieldBind как раз должен совпадать с Parameter/Name. Для элементов Parameter задается C#-тип этого параметра, а также направление (In или Out) и некоторые другие свойства. Параметры уже непосредственно передаются в C# код, который реализует данный Workflow Action. Вот как выглядит XML, задающий параметры для нашего случая:

<Parameters>
  <Parameter Name="__Context"
              Type="Microsoft.SharePoint.WorkflowActions.WorkflowContext, Microsoft.SharePoint.WorkflowActions"
              Direction="In"
              DesignerType="Hide"/>
  <Parameter Name="startDate"
              Type="System.DateTime, mscorlib"
              Direction="In"
              DesignerType="Date"
              Description="Start date of the holidays period" />
  <Parameter Name="endDate"
              Type="System.DateTime, mscorlib"
              Direction="In"
              DesignerType="Date"
              Description="End date of the holidays period" />
  <Parameter Name="Result"
              Type="System.Int32, mscorlib"
              Direction="Out"
              DesignerType="ParameterNames"
              Description="Number of holidays between two dates." />
</Parameters>

Параметр __Context - служебный, в процессе исполнения он будет автоматически подменен объектом контекста Workflow.

Обратите внимание, здесь еще раз задается DesignerType. Этот атрибут определяет вид дизайнера в PropertyGrid. Он вполне может отличаться от DesignerType соответствующего элемента FieldBind.

Результирующий PropertyGrid с параметрами заданными приведенным выше XML будет выглядеть следующим образом:

Сразу отмечу, что порядок элементов Parameter важен. Именно в этом порядке параметры будут передаваться в наш метод-обработчик.

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

  <WorkflowActions>
    <Action Name="Count Holidays"
            SandboxedFunction="true"
            Assembly="$SharePoint.Project.AssemblyFullName$"
            ClassName="MyProject.CustomActions"
            FunctionName="CountHolidays"
            UsesCurrentItem="true"
            AppliesTo="all"
            Category="Utility Actions">
      <RuleDesigner Sentence="Count holidays between %1 and %2 (result to %3)">
        ...
      </RuleDesigner>
      <Parameters>
        ...
      </Parameters>
    </Action>
  </WorkflowActions>

В случае затруднений с XML, примеры определения имеющихся в SharePoint Workflow Actions в XML-виде можно найти в папке 14\TEMPLATE\1033\Workflow, в файлах *.actions.

Да, последнее про XML: этот XML деплоится через модуль, т.е. этот XML-код должен быть помещен в Elements.xml.

Метод-обработчик

Наконец, XML написан, и теперь можно переходить наконец-то на C#. Как не трудно догадаться, метод-обработчик задается в XML атрибутами Assembly, ClassName и FunctionName элемента Action.

Метод должен возвращать Hashtable, и принимать все параметры обозначенные в XML, строго в том порядке, в котором идут элементы Parameter. Типы, ясное дело, тоже должны соответствовать заявленным. А вот имя параметра можно сделать другим (но лучше тоже чтобы они совпадали, просто чтобы не запутаться потом).

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

public Hashtable CountHolidays(SPUserCodeWorkflowContext context, DateTime startDate, DateTime endDate)

Возвращать значения нужно в Hashtable, ключ значения должен соответствовать значению атрибута Parameter/Name в XML. Т.е. в нашем случае будем возвращать значение в hashtable["Result"].

Зная это, осталось только написать собственно код для подсчета количества выходных согласно заданному вами алгоритму, используя объект контекста и переданные параметры.

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

public Hashtable CountHolidays(SPUserCodeWorkflowContext context, DateTime startDate, DateTime endDate)
{

    using (SPSite site = new SPSite(context.CurrentWebUrl))
    {
        using (SPWeb web = site.OpenWeb())
        {
            try
            {
                var list = web.Lists[context.ListId];
                var item = list.GetItemById(context.ItemId);
                        
                var holidaysList = // здесь получайте список с праздниками
                var query = new SPQuery()
                {
                    ViewFields = @"<FieldRef Name=""ID"" />",
                    ViewFieldsOnly = true,
                    Query = String.Format(@"<Where>
                        <And>
                            <Geq>
                                <FieldRef Name=""{0}"" />
                                <Value IncludeTimeValue=""FALSE"" Type=""DateTime"">{1}</Value>
                            </Geq>
                            <Lt>
                                <FieldRef Name=""{0}"" />
                                <Value IncludeTimeValue=""FALSE"" Type=""DateTime"">{2}</Value>
                            </Lt>
                        </And>
                        </Where>", 
                        "HolidayDateFieldInternalName", 
                        SPUtility.CreateISO8601DateTimeFromSystemDateTime(startDate.Date), 
                        SPUtility.CreateISO8601DateTimeFromSystemDateTime(endDate.Date.AddDays(1)))
                };
                var items = holidaysList.GetItems(query);

                return new Hashtable() { { "Result", items.Count } };
            }
            catch (Exception ex)
            {
                SPWorkflow.CreateHistoryEvent(web, context.WorkflowInstanceId, 0, web.CurrentUser, TimeSpan.Zero, "Error", ex.Message + " Stack trace: " + ex.StackTrace, string.Empty);
                return new Hashtable() { { "Result", 0 } };
            }
        }
    }

}

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

Замечание: приведенные выше код и XML относятся к созданию Sandboxed Workflow Custom Action. Обычные серверные Custom Workflow Actions имеют свои преимущества - к примеру, они позволяют запускать код с повышенными привилегиями, что в Sandbox'е сделать не получится. Такие Workflow Actions работают немного по-другому и определение метода будет другим (хотя XML примерно такой же). Как создавать серверные Workflow Actions, описано например здесь.

Где еще взять Workflow Custom Actions

На codeplex можно найти десятки Custom Actions, уже созданных для вас. Вы можете использовать их как пример, дорабатывать, изменять и т.п. - ведь это Opensource! Например, spdactivities.codeplex.com.

Кроме того, есть компании, которые продают пакеты Custom Actions, и там попадаются очень даже интересные элементы. Например, HarePoint Workflow Extensions - сам не использовал, но на взгляд выглядит интересно.

Заключение

SPD Workflow - на самом деле очень даже гибкая штука, благодаря возможности создания собственных Workflow Actions. В SharePoint 2013, как известно, Visual Studio Workflows уже работают вообще только в режиме совместимости...

Про эффективность и продуктивность

2013-04-26T09:00:00.000+04:00

Делать быстро и делать именно то, что надо - это идеал, который на самом деле никому не нужен. Да-да, я не ошибся! Реальность - грустная штука и иногда нелогичная, но от нее никуда не убежать :(

Моя история

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

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

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

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

Итак, что я делал, чтобы этого добиться:

Установил RescueTime (в минимальном, бесплатном варианте). Очень классная утилита, которая позволяет отследить, сколько ты работаешь в том или ином приложении. Приложения распределены по категориям, и каждая категория оценивается от -2 до +2 (это все настраивается). Фишка состоит в том, что через месяц-два тебе надоедает постоянно следить за своими отчетами, НО умный RescueTime присылает еженедельные отчеты, и сразу видно, если "расслабился" и надо "подтянуть" концентрацию.
Читал статьи, смотрел доклады по этой теме - особенно классный доклад от Хансельмана.
Стал планировать свои дела - кстати не только рабочие, но и персональные (такие в частности, как отъезд в Финляндию и все необходимое для этого).
Изучал Usability и UX, чтобы понимать, что действительно удобно для пользователей, а что нет. Как следствие, я начал задавать более правильные вопросы при анализе задач, и соответственно, стал работать с большей результативностью и с большей пользой для всех.

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

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

Почему быть слишком продуктивным - вредно?

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

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

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

И здесь вы начинаете чувствовать себя некомфортно. "Нифига себе молодец," - думаете вы, - "10 тысяч за полчаса. Это кто ж такие деньги зарабатывает!".

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

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

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

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

(Если кому-то интересно узнать, почему так происходит - рекомендую курс Dan Arley про иррациональное поведение на Coursera)

Почему работать целый день без остановки - нельзя в принципе?

По многим причинам:

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

На практике это означает, что нельзя сидеть за компьютером 8 часов в день и писать код. Это неправильно и неэффективно. Т.е. рано или поздно вы себя обнаружите гуляющим по офису и "ничего не делающим" с точки зрения начальства. Это неизбежно.

Если соединить эти рассуждения с тем, о чем я рассказывал в предыдущем параграфе, получаем, что эффективным и продуктивным людям НИКТО не хочет платить деньги. Это факт :)

Кстати отсюда же напрямую исходит, что невозможно сократить часы своей работы официальными методами. Например, я хороший специалист, я хочу работать 4 часа в день вместо 8, и больше тратить на семью. Я уверен, что я буду делать не меньше по объему за 4 часа, чем мой сосед "Вася" за 8 - и хочу получать за 4 часа такую же зарплату, как он за восемь. НЕ ПОЛУЧИТСЯ! Точнее, делать столько же получится, а получать за 4 часа такую же зарплату - нет. Причем, на вдвое большую зарплату за 8 часов договориться еще реально, но сокращение рабочего дня - нет. Психология, блин.

Как решить эту проблему?

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

Но мне кажется, можно кое-что придумать и работая "на дядьку":

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

Если вкратце, работать нужно так, чтобы никто не видел процесса, а все видели только результат.

Заключение

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

P.S. Не стесняйтесь свои мысли/опыт по этому поводу скидывать в комменты. Обсудим :)

Загадочный список Survey

2013-04-23T09:00:00.000+04:00

Список типа "Опрос" в SharePoint - очень интересный и особенный. Прежде всего, уникальность его заключается в том, что он позволяет вставлять разделители страниц (Page separator), т.е. по сути разбивать форму создания элемента списка на страницы!

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

Page Separator - это особый тип поля (SPFieldType.PageSeparator), доступный только для списков типа Survey. По сути это обычная колонка списка, не содержащая никаких данных. Если при выводе полей на форму встречается колонка этого типа, это считается окончанием страницы и следующие поля не выводятся. Также для реализации этого механизма используется параметр командной строки "FirstField", который определяет, начиная с какого поля выводить форму:

Более того, переходы на разные страницы можно даже сделать условными с помощью фишки, которая называется "Branching logic":

Т.е. в зависимости от выбора пользователя, можно пропустить следующую страницу опроса, и т.д.

Конечно, список типа "Survey" ориентирован прежде всего на создание опросов. Однако, в некоторых ситуациях его вполне можно использовать и для других бизнес нужд. Живой пример: регистрации на встречи Russian SharePoint User Group на сайте rusug.net всегда были реализованы именно с помощью обычного списка "Survey" (хоть и без разбития на страницы).

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

Ответить на опрос можно только один раз. Это автоматически означает, что один пользователь может заполнить форму лишь единожды, т.е. создать только 1 элемент списка. Для регистрации на событие это вполне нормально, а вот оформление заказов таким образом уже не сделаешь...
Update: Спасибо Алексею за комментарий! Оказывается, при создании списка есть дополнительная опция "Allow multiple responses", которая решает эту проблему.
Бэкэнд заточен под создание вопросов и ответов, и везде используется соответствующая терминология. Если вы планируете давать клиенту возможность изменять этот список (добавлять в него поля и т.п.), надо готовиться, что придется пускаться в пространные объяснения, что это там за вопросы и ответы такие :)
Веб-интерфейс настроек списка сильно урезан. Например, через настройки списка в браузере нельзя создавать представления (хотя через SharePoint Designer или программно представления создаются без проблем).
Survey - это, пожалуй, единственный тип списка, у которого до сих пор остался старый тип тулбара, из 2007го SharePoint'а. Интеграция с риббоном отсутствует.

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

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

Как устроен Survey List

Оказывается, реализация многостраничности в опросах довольно простая. Она основывается на переопределенном RenderingTemplate. Вы можете найти этот шаблон в файле CONTROLTEMPLATES/DefaultTemplates.ascx, называется SurveyForm:

<SharePoint:RenderingTemplate id="SurveyForm" runat="server">
    <Template>
        <wssuc:ToolBar CssClass="ms-formtoolbar" id="toolBarTbltop" RightButtonSeparator="&amp;#160;" runat="server">
            <Template_RightButtons>
                <SharePoint:NextPageButton runat="server"/>
                <SharePoint:SaveButton Text="<%$Resources:wss,tb_survey_save%>" accesskey="<%$Resources:wss,tb_survey_save_AK%>" runat="server"/>
                <SharePoint:MultiPageGoBackButton runat="server"/>
             </Template_RightButtons>
        </wssuc:ToolBar>
        <SharePoint:FormToolBar runat="server"/>
        <SharePoint:ItemValidationFailedMessage runat="server"/>
        <table class="ms-formtable" style="margin-top: 8px;" border="0" cellpadding="0" cellspacing="0" width="100%">
        <SharePoint:SurveyFieldIterator runat="server"/>
        </table>
        <table cellpadding="0" cellspacing="0" width="100%"><tr><td class="ms-formline"><img src="/_layouts/15/images/blank.gif?rev=23" width='1' height='1' alt="" /></td></tr></table>
        <table cellpadding="0" cellspacing="0" width="100%" style="padding-top: 7px"><tr><td width="100%">
        <SharePoint:ItemHiddenVersion runat="server"/>
        <wssuc:ToolBar CssClass="ms-formtoolbar" id="toolBarTbl" RightButtonSeparator="&amp;#160;" runat="server">
                <Template_Buttons>
                        <SharePoint:InitContentType runat="server"/>
                        <SharePoint:CreatedModifiedInfo runat="server"/>
                </Template_Buttons>
                <Template_RightButtons>
                    <SharePoint:NextPageButton runat="server"/>
                    <SharePoint:SaveButton Text="<%$Resources:wss,tb_survey_save%>" accesskey="<%$Resources:wss,tb_survey_save_AK%>" runat="server"/>
                    <SharePoint:MultiPageGoBackButton runat="server"/>
                </Template_RightButtons>
        </wssuc:ToolBar>
        </td></tr></table>
    </Template>
</SharePoint:RenderingTemplate>

Для многостраничной логики, здесь задействованы контролы, обозначенные жирным. Наиболее интересным на первый взгляд здесь представляется контрол SurveyFieldIterator. Он реализует логику отображения полей на форме. Если подсмотреть на этот класс через рефлектор или его аналог, вы увидите, что логика отображения на удивление простая и даже в некотором роде элегантная (если элегантный говнокод существует - то это как раз он! :) ).

Хорошие новости: SurveyFieldIterator будет работать для любого списка - т.е. довольно легко его задействовать в каком-нибудь другом, кастомном списке. Плохие новости: в контролы NextPageButton и SaveButton захардкожены проверки на шаблон списка (SPListTemplateType.Survey), и использовать их в кастомном списке не выйдет :(

Заменить эти контролы очень непросто, потому что они используют некоторые методы, помеченные как internal (т.е. только через Reflection, чего я стараюсь избегать). Обойтись без них тоже никак - ведь именно кнопка "NextPageButton" обеспечивает промежуточное сохранение элемента списка и реализует кучу другой интересной логики. В общем, после нескольких часов ковыряния в рефлекторе, я так и не смог найти нормального способа сделать многостраничный список в SharePoint таким же способом, как сделан список Survey, т.е. через ListFieldIterator... :(

Помимо невозможности замены NextPageButton, есть кстати и другие ограничения. К примеру, поле PageSeparator через веб-интерфейс доступно только для списков типа Survey. Впрочем, это поле очень легко добавить программно, или например вот таким простейшим PowerShell-скриптом:

$w = get-spweb http://localhost
$l = $w.Lists["My List"]
$l.Fields.Add("PageSeparator", [Microsoft.SharePoint.SPFieldType]::PageSeparator, $false, $false, $null)

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

Branching Logic иногда тоже было бы полезно использовать, но и эта фишка в UI доступна только для списков типа "Опрос". Так что тут снова придется либо действовать PowerShell-ом, либо писать отдельный UI - если требуется, чтобы пользователи сами могли настраивать логику отображения формы (что, кстати, требуется крайне редко).

Также, следует отметить, что стандартные кнопки Save и Cancel работать не должны. Впрочем, убрать их с Ribbon довольно легко следующим Custom Action:

<CustomAction Id="RemoveRibbonButton" Location="CommandUI.Ribbon">
  <CommandUIExtension>
    <CommandUIDefinitions>
     <CommandUIDefinition Location="Ribbon.ListForm.Edit.Commit" />
    </CommandUIDefinitions>
  </CommandUIExtension>
</CustomAction>

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

Заключение

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

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

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

Что же касается многостраничных форм - реализовывать их в SharePoint сейчас на удивление тяжело - на мой взгляд это в некотором роде прокол со стороны MS, ведь бизнес-кейс это очень частый. Есть у них конечно полуживой InfoPath и малополезный Scenario Framework, но InfoPath - действительно полуживой и полон собственных ограничений и багов, а Scenario Framework - мало что дает по сравнению с обычным ASP.Net-визардом, созданным "вручную". В настоящий момент наиболее перспективным подходом к задаче многостраничных форм мне лично видится использование Client Side Rendering (CSR) из SharePoint 2013 - но это пока что подход не проверенный. Если будет шанс реализовать многостраничную форму на CSR, я этим обязательно с вами поделюсь, а на сегодня у меня все. Удачи!

Атрибуты ViewFields

2013-04-22T09:06:00.000+04:00

С первого взгляда, ViewFields - это попросту список полей, которые отображаются в том или ином представлении списка. В C# API этот список полей представлен классом SPViewFieldCollection, который является по сути коллекцией строк, представляющих собой InternalName полей, отображаемых представлением.

Немногие знают, что каждое поле внутри ViewFields (элементы FieldRef) еще может иметь атрибуты, которые определяют, как именно это поле включается в представление списка. Большая часть этих атрибутов присутствует у исходных SPField (однако не все атрибуты SPField переопределяемы!), и установка их в FieldRef позволяет просто переопределить (override) настройки поля в рамках конкретного представления.

Меню элемента

Пожалуй, одни из самых известных и используемых атрибутов элементов ViewFields - это LinkToItem и ListItemMenu. Они позволяют "подцепить" соответственно ссылку на Display форму элемента и меню элемента на произвольное поле списка - без всяких там XSLT преобразований. Нередко эти атрибуты используются, например, в библиотеках документов, где вместо имени файла предпочтительнее отображать заголовок документа (Title) - и соответственно, меню элемента должно быть перенесено на заголовок.

<FieldRef Name="MyField" LinkToItem="TRUE" ListItemMenu="TRUE" />

В SharePoint 2013, к слову, добавился похожий атрибут "CalloutMenu", который позволяет отобразить более современное меню элемента вида "Callout".

Фильтрация и сортировка

Установка атрибутов Filterable и Sortable в FALSE поможет запрещать фильтрацию и сортировку выбранных полей в пределах вашего представления. Дополнительно, можно указать сообщение, которое будет отображаться, когда фильтрация недоступна (атрибут FilterDisableMessage).

Когда это требуется?

Например, вы выносите фильтр по некоторому полю в отдельную панель наверху представления, и улучшаете этот фильтр, делаете его более "user friendly". Скажем, вместо фильтрации по конкретной дате, вы предлагаете пользователю выбрать месяц/год или даже лучше - выбрать конкретный диапазон дат. В этом случае фильтр в заголовке колонки становится ненужным, и почему бы его не запретить.
В некоторых полях фильтрация просто выглядит глупо (яркий пример - поле "Title").
Когда вы используете в запросе представления (тэг <Query>) параметры (значения из ParameterBindings), фильтры SharePoint ломаются, т.е. не выдают вариантов для фильтрации, как будто в колонке совсем нет данных. В этом случае я предпочитаю явно запрещать фильтрацию и определять сообщение об ошибке для всех полей, что-нибудь типа "В этом представлении фильтрация невозможна"...

Explicit

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

Explicit делает две вещи:

Скрывает поле из представления. Т.е. данные для поля будут запрашиваться и поступать в XSLT преобразование, но отображаться соответствующие поля не будут, пока вы их сами не отобразите.
Не дает пользователю удалить поле из представления!!

Те люди, которые используют свойство Sealed у SPField, меня поймут! :)

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

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

SharePoint 2013

В SharePoint 2013, помимо уже упоминавшегося выше CalloutMenu, к ViewFields добавилось немало новых интересных атрибутов. В частности, это атрибуты для управления отображением полей типа "Пользователь": WithPicture, PictureSize, PictureOnly, и некоторые другие.

Например, добавление WithPicture="TRUE" к полю "Created By" (InternalName="Author") выдает вот такой результат:

А вот такой FieldRef:

<FieldRef Name="Author" PictureSize="Size_36px" PictureOnly="TRUE" />

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

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

Еще один атрибут, специфичный для SP2013, о котором хотелось бы упомянуть - это AllowGridEditing. Он позволяет сделать ту или иную колонку нередактируемой в режиме Grid в рамках данного представления. Выглядит полезно, но будьте осторожны: ограничение редактирования такого рода запретами ненадежно, всегда можно будет изменить это поле куском JS через Client Object Model. О том, как правильно управлять разрешениями и доступом в SharePoint, у меня есть отдельная статья.

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

Другие атрибуты

Есть для элементов ViewFields/FieldRef и другие атрибуты. Например, атрибуты Len и MoreText, нужные для обрезания текста...

Еще один атрибут, тоже иногда пригождающийся - это AutoHyperLink. Он позволяет внутри обычного текстового поля разрешить абсолютные URL-ссылки. Результат выглядит примерно так:

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

Как задать атрибуты ViewFields программно?

Как я уже упоминал выше, через SPView.ViewFields задать эти атрибуты нельзя. Что же делать?

Очевидно, решение - это попробовать как-то передать в SPView кусок View XML. К сожалению, напрашивающийся для этого метод SetViewXml попросту не работает - проглатывает любой поданный ему XML, но после Update изменения не сохраняются в БД.

Впрочем, если тщательно пошарить в MSDN, вы обнаружите, что конструктор SPView принимает XmlDocument, что практически то что нужно! Однако, метод Update на созданном таким образом SPView, как ни странно, не работает!... Решение этой проблемы можно найти там же в MSDN, в секции Remarks:

Use the Clone method on the constructed view object to add the view to collection of views for the list.

Кто бы мог подумать! Создаем SPView используя конструктор, а потом его клонируем, и вот тогда уже можно сохранять. Система нипель, блин :)

Вот вам рабочий код:

var doc = new XmlDocument();
doc.LoadXml("<View ...>...</View>"); // or load from file: doc.Load("myview.xml");
var tempView = new SPView(list, doc);
var view = tempView.Clone("My view", 30, true, false);
view.Update();

Заключение

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