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

Ближе к делу. Предположим, что часть нашего решения описана следующим кодом:

return this.MyIncompletedTasks
  .Where(t => t.Deadline < DateTime.Now).ToList();

Не вдаваясь в подробности, тут мы выводим список просроченных задач для текущего пользователя (исполнителя).

И вот какой CAML-запрос нам генерирует DataContext (его существенная для дальнейшего обсуждения часть):

<Where>
  <And>
    <And>
      <BeginsWith>
        <FieldRef Name="ContentTypeId" />
        <Value Type="ContentTypeId">
          0x0100BD4F0AA735D045489D088CAD29AAE25E00
        </Value>
      </BeginsWith>
      <Eq>
        <FieldRef Name="Performer" LookupId="TRUE" />
         <Value Type="User">1</Value>
      </Eq>
    </And>
    <Lt>
      <FieldRef Name="EndDate" IncludeTimeValue="TRUE" />
      <Value Type="DateTime">2010-08-11T17:24:22Z</Value>
    </Lt>
  </And>
</Where>

Обращаю внимание читателя на атрибут IncludeTimeValue. Исходя из названия которого легко сделать вывод о том, что в запросе будет учитываться не только значение даты, но и значение времени. Однако этого не происходит, сравниваются именно даты и полностью игнорируется время. Как нетрудно догадаться, коллеги из MS забыли засунуть этот же атрибут в элемент Value. Чтобы все заработало, нужно было сделать так:

<Lt>
  <FieldRef Name="EndDate" IncludeTimeValue="TRUE" />
  <Value Type="DateTime" IncludeTimeValue="TRUE">2010-08-11T17:24:22Z</Value>
</Lt>

Немного покрутив рефлектор, можно найти код, ответственный за формирование элемента Value. Этим занимается метод SetValue класса Microsoft.SharePoint.Linq.SPDataQuery. Вот его код (жирным курсивом выделены мои правки, позволяющие исправить проблемы с временем):

string str;
switch (field.FieldType)
{
  case SPDataFieldType.DateTime:
    str = SPUtility.CreateISO8601DateTimeFromSystemDateTime(
      (DateTime)value);
    break;
  case SPDataFieldType.Boolean:
  case SPDataFieldType.Attachments:
  case SPDataFieldType.Recurrence:
  case SPDataFieldType.CrossProjectLink:
  case SPDataFieldType.AllDayEvent:
    str = ((bool)value) ? "1" : "0";
    break; 
  default:
    str = value.ToString();
    break;
}
xwriter.WriteStartElement("Value");
xwriter.WriteAttributeString("Type", JoinPath.IsValidJoinPath(field.JoinPath) ? "Lookup" : field.FieldType.ToString());
if (field.FieldType == SPDataFieldType.DateTime)
{
  xwriter.WriteAttributeString("IncludeTimeValue", "TRUE");
}
xwriter.WriteValue(str);
xwriter.WriteEndElement();

Уважаемые разработчики компонента Microsoft.SharePoint.Linq.dll! Оторвитесь от просмотра любимого сериала, катания на велосипеде, лежания на пляже с бокалом коктейля и допишите, наконец-то 4 строчки кода! Общественность негодует и требует от вас исправления этой пусть небольшой, но крайне досадной проблемы.

Ну, пожааааалуйста, нам очень надо…

Микрософт по какой-то причине отключил возможность использования навигации при помощи метаданных по списку страниц в корпоративной вики (Enterprise Wiki). Однако ее можно заставить работать. Для этого нужно:

1. Перейти в свойства списка (адрес списка: http://<путь_до_узла>/Pages/Forms/AllItems.aspx).
2. В адресной строке заменить listedit.aspx на MetaNavSettings.aspx.
3. Добавить необходимые поля и сохраниться.
4. Открыть в Sharepoint Designer узел и немного поправить v4.master: добавить ссылку на контрол отображения навигации: <%@ Register TagPrefix="wssuc" TagName="MetadataNavTree" src="~/_controltemplates/MetadataNavTree.ascx" %> и сам контрол: <wssuc:MetadataNavTree id="mdnt" runat="server" />. Сохраняем.
5. Открываем контекстное меню для измененного v4.master и выбираем Set as Default Master Page.
6. Результат:

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

Ну да ладно, может быть кому-нибудь будет полезен сам способ решения проблемы.

По-русски ссылка называется Параметры значений по умолчанию для столбцов. Для примера я создал 2 столбца типа число и текст: Document number и Document Date.

Кстати, фича не поддерживает TaxonomyField, что весьма печально :(.

Задаются значения очень просто, к счастью, нам не нужно как в прошлый раз химичить с рефлексией. Все что необходимо — класс MetadataDefaults из сборки Microsoft.Office.DocumentManagement.dll:

using (SPSite site = new SPSite("http://localhost"))
{
  SPWeb web = site.OpenWeb();
  SPList list = web.Lists["Shared Documents"];

  MetadataDefaults defaults = new MetadataDefaults(list);
  defaults.RemoveAllDefaults();
  defaults.SetFieldDefault(list.RootFolder,
    "Document_x0020_number", 500.ToString());
  defaults.SetFieldDefault(list.RootFolder,
    "Document_x0020_Date",
    SPUtility.CreateISO8601DateTimeFromSystemDateTime(
      new DateTime(2010, 6, 16)));
  defaults.Update();
}

Здесь применяются значения по-умолчанию для корневой папки библиотеки документов Shared Documents. В качестве имени поля нужно передавать его InternalName. Дату следует передавать в формате ISO8601 строкой, иначе страница будет падать :).

Выполнив этот нехитрый код, мы получим:

Свежезагруженный документ будет с заполненной карточкой.

Кроме того, у класса MetadataDefaults есть метод ApplyDefaults, которое в качестве параметра принимает SPListItem. Думаю, назначение этого расчудесного метода не требует комментариев :). Применяется он так:

SPListItem item = list.GetItemById(1);
MetadataDefaults defaults = new MetadataDefaults(list);
defaults.ApplyDefaults(item);
item.Update();

Несмотря на адскую жару, по заявкам трудящихся, публикую воркэраунд как можно программно активировать опции в разделе “Enterprise Metadata and Keywords Settings” (или, говоря по-русски, “Параметры корпоративных метаданных и ключевых слов”):

Как выяснилось, Микрософт зачем-то захотели засекретить программную работу с этими настройками. Не очень умно :(. А что если надо взять и применить эти настройки ко всем спискам определенного типа на всех узлах определенного шаблона? Не будем унывать, ведь у нас есть Reflection! Пишем несложный код (я для примера использую библиотеку документов “Shared Documents”):

using (SPSite site = new SPSite("http://localhost"))
{
  SPWeb web = site.OpenWeb();
  SPList list = web.Lists["Shared Documents"];

  Assembly taxonomy =
    Assembly.LoadWithPartialName("Microsoft.SharePoint.Taxonomy");

  Type settingsType = taxonomy
    .GetType("Microsoft.SharePoint.Taxonomy.MetadataListFieldSettings");
  object settings = settingsType
    .GetConstructor(new Type[] { typeof(SPList) })
    .Invoke(new object[] { list });
  settingsType.GetProperty("EnableKeywordsField",
    BindingFlags.NonPublic | BindingFlags.Instance)
    .SetValue(settings, true, null);
  settingsType.GetProperty("EnableMetadataPromotion",
    BindingFlags.NonPublic | BindingFlags.Instance)
    .SetValue(settings, true, null);
  settingsType.GetMethod("Update", BindingFlags.NonPublic |
    BindingFlags.Instance).Invoke(settings, null);
}

Здесь свойство EnableKeywordsField соответствует опции “Enterprise Keywords” (“Корпоративные ключевые слова”), a “EnableMetadataPromotion” — “Metadata Publishing” (“Публикация метаданных”).

Далее: Sharepoint 2010: Metadata and Taxonomy (Part 8). Enable metadata navigation on Enterprise Wiki

© lord-k

Пятница :)

Одна из новых фич SharePoint 2010 связана с кнопкой “I Like It” (или “Мне нравится”), которая представляет собой некий аналог избранного в браузере.

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

Для написания кода нам потребуются следующие сборки: Microsoft.SharePoint.dll, Microsoft.SharePoint.Taxonomy.dll и Microsoft.Office.Server.UserProfiles.dll.

Код:

UserProfileManager profileManager = new UserProfileManager();
UserProfile currentUser = profileManager.GetUserProfile(true);

SocialTagManager tagManager = new SocialTagManager();

rptILikeItLinks.DataSource = tagManager.GetTags(currentUser)
    .Where(t => t.Term.GetDefaultLabel(1033) == "I like its")
    .Select(t => new { Url = t.Url.AbsoluteUri, Title = t.Title });
rptILikeItLinks.DataBind();

Здесь rptILikeItLinks — это Repeater:

<asp:Repeater ID="rptILikeItLinks" runat="server">
    <ItemTemplate>
        <a href=’<%# Eval("Url") %>’><%# Eval("Title") %></a>
    </ItemTemplate>
</asp:Repeater>

Для русскоязычного Шарепоинта надо использовать локаль 1049 и тег “Мне нравится”, ну или задать их каким-нибудь другим хитрым образом :)

SharePoint 2010: Metadata and Taxonomy (Part 7). Programmatically enable “Enterprise Metadata and Keywords Settings” options.

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

using (SPSite site = new SPSite(http://localhost))
{
  SPWeb web = site.OpenWeb();
  SPListItem news = web.Lists["News"].AddItem();

  news["Tags"] = tagsValues;
  news.Update();
}

Результат:

SharePoint 2010: Metadata and Taxonomy (Part 6). I Like It!

Те, кто хоть раз в жизни использовал Linq to SQL, не обнаружат большой разницы в сгенерированной объектной модели, однако, работать нам придется не в гламурненьком дизайнере 2010 студии, а в суровом консольном SPMetal. Обо всем по порядку.

Чтобы было на чем тренироваться создадим узел по какому-нибудь шаблону, например, “Сайт группы”. Затем создадим на нем два списка: “Договоры” и “Контрагенты”, добавим в них типы содержимого (которые зачем-то переименовали в “Типы контента”; лично я ни от кого такого странного названия не слышал):

• Контрагент
  • Название
  • Юридический адрес
• Договор
  • Номер
  • Дата
  • Контрагент (лукап на список Контрагентов)

Заполняем парой контрагентов и парой договоров. На этом подготовительный этап завершен.

Открываем с админискими привилегиями консоль и переходим в папку “C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\BIN”. Выполняем следующий скрипт:

SPMetal /web:http://localhost/TeamSite
/namespace:Linq2SharePoint /code:c:\TeamSite.cs

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

Решить некоторые проблемы может специальный XML-файл с параметрами кодогенерации. Например, такой:

<?xml version="1.0" encoding="utf-8" ?>
<Web xmlns="http://schemas.microsoft.com/SharePoint/2009/spmetal" Class="TeamSiteWeb" AccessModifier="Public">
  <List Name="Договоры">
    <ContentType Class="Contract" Name="Договор" />
  </List>
  <List Name="Контрагенты">
    <ContentType Class="Contractor" Name="Контрагент" />
  </List>
  <ExcludeOtherLists />
  <ContentType Class="Item" Name="Элемент" />
  <ContentType Class="ContractBase" Name="Договор" />
  <ContentType Class="ContractorBase" Name="Контрагент" />
</Web

Здесь мы указываем какие списки мы включаем, для каких типов контента будем генерировать код и как эти типы назовем. Сохраняем файл в папку с SPMetal под именем codeparameters.xml Запускаем тот же скрипт с дополнительным параметром /parameters:codeparameters.xml. Вот это другое дело! Никакой кириллицы в названии типов и сгенерированы только нужные типы! Но при этом у нас остались кириллические символы в названии свойств и полей. Предлагаю побороть их читателю самостоятельно, воспользовавшись XSD-схемой.

Создадим консольное приложение и попробуем использовать на практике сгенерированный код. Нам понадобятся две сборки: Microsoft.SharePoint.dll и Microsoft.SharePoint.Linq.dll.

Для того, чтобы вывести все номера договоров нашей воображаемой конторы с конкретным контрагентом, напишем несложный код (изменять имена свойств мне было лень):

using (TeamSiteWeb web = new TeamSiteWeb("http://localhost/teamsite"))
{
var query = web.Договоры.Where(c => c.Контрагент.Название == "Microsoft");
  foreach (var contract in query)
  {
    Console.WriteLine(contract.Номер);
  }
}

Тут интересно вот что: мы извлекаем записи из одного списка по фильтру из другого. В 2007 Sharepoint это было бы возможно только перебором в клиентском коде. Можно конечно было использовать Linq 2 Objects с Joinами, но сути это не меняет.

А представленный выше код транслируется вот в такой замечательный CAML:

<View>
<Query>
<Where>
<And>
<BeginsWith>
<FieldRef Name="ContentTypeId" />
<Value Type="ContentTypeId">0x010092CA7ECAD2EC6847960E9CFFF1C0872D00</Value>
</BeginsWith>
<Eq>
<FieldRef Name="_x041a__x043e__x043d__x0442__x04Title" />
<Value Type="Lookup">Microsoft</Value>
</Eq>
</And>
</Where>
</Query>
<ViewFields>
<FieldRef Name="_x041d__x043e__x043c__x0435__x04" />
<FieldRef Name="_x0414__x0430__x0442__x0430_" />
<FieldRef Name="_x041a__x043e__x043d__x0442__x04" LookupId="TRUE" />
<FieldRef Name="ID" />
<FieldRef Name="owshiddenversion" />
<FieldRef Name="FileDirRef" />
<FieldRef Name="Title" />
</ViewFields>
<ProjectedFields>
<Field Name="_x041a__x043e__x043d__x0442__x04Title" Type="Lookup" List="_x041a__x043e__x043d__x0442__x04" ShowField="Title" />
</ProjectedFields>
<Joins>
<Join Type="LEFT" ListAlias="_x041a__x043e__x043d__x0442__x04">
<Eq>
<FieldRef Name="_x041a__x043e__x043d__x0442__x04" RefType="ID" />
<FieldRef List="_x041a__x043e__x043d__x0442__x04" Name="ID" />
</Eq>
</Join>
</Joins>
<RowLimit Paged="TRUE">2147483647</RowLimit>
</View>

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

Конечно, это вам не join в SQL и не стоит ждать какой-то суперэффективности, однако свои плюсы безусловно имеются: во-первых он в любом случае более нативный, чем наш клиентский Join (на основе Linq 2 Objects, например), во-вторых клиентский код получается более простым и чистым (представили как заджойнить хотя бы 5 списков в SharePoint 2007? ;-)).

Подводя итог, отмечу, что хотя Linq 2 SharePoint и привносит в нашу жизнь немного радости, у технологии есть и пара недоделок:

• нет возможности работать из дизайнера студии,
• сгенерированный код приходится постоянно дописывать, дополняя его ссылками на родительский SPList и SPWeb, методами для работы с вложениями и раздачей прав доступа.