F#, вторая серия. Параллельная.
Попытка соорудить способ параллельного выполнения кода по запросу данных из нескольких списков Sharepoint. Собственно, способ предполагалось использовать в веб-части, написанной на C#, выбор F# для реализации способа обусловлен наличием в нём средств для параллельного выполнения асинхронных операций (класс Async).
Упрощённая тестовая программка на C#:
Параллельный исполнятель на F#:
Однако фокус не удался: из всех списков, переданных в ParallelExecutor, данные добываются только из одного (иногда из первого, иногда из последнего). На всех остальных операция list.Items.GetDataTable() падает с диковинным сообщением <nativehr>0×80010102</nativehr><nativestack></nativestack> 
Похоже, разработчики Sharepoint не сумели подружиться не только с .NET 4.0, но и с F#-классом Async…
Веб-часть XmListViewer 2010
На базе версии XmListViewer 2007 сделал веб-часть XmListViewer 2010 для работы на фермах Sharepoint 2010. Собственно, практически только рефакторинг кода да использование некоторых фич SPF 2010 и понравившихся функциональных приёмчиков. Расширил функциональность light-версии – теперь можно получать данные одновременно из двух списков.
Функциональное нововведение одно – консолидация данных списков на узлах Шарепойнт на манер стандартной веб-части “Запрос контента” с некоторыми расширениями (или уходами в сторону?).
В процессе реализации преисполнился благодарностей (надеюсь, от икоты никто не умер…) разработчикам Sharepoint, исключившим из него возможность параллельного исполнения кода (в WSS 2007 такая возможность была с использованием библиотеки ParallelExtensions, теперь она включена в .NET 4.0, с которым разработчики Sharepoint подружиться не сумели 
) – при консолидации списков набирается много, а запрос данных дорог и прямо напрашивается на параллельное исполнение…
Ко всем прочим удовольствиям добавилась новелла с нерабочим редактором страниц на officelive.com (может, и починят, может, и навсегда…). Поэтому отдельную страничку сделать пока не удаётся, ссылки на закачку здесь – Light-версия веб-части, инструкция по установке и настройке.
Добавил.
Страничку сделать удалось – http://dyakov.design.officelive.com/xmliv2010.aspx. Там все необходимые ссылки для установки.
Хвала Reflection.
Потребовалось в проекте выгружать на диск документы из библиотек Шарепойнт. На первый взгляд – ничего особенного: запрашиваем у пользователя путь к папке сохранения на манер модуля резервного копирования в Центре Управления, подключаем пространство имён System.IO, класс DirectoryInfo, методы CreateSubdirectory, file.OpenBinary() + stream.Write() – и все дела. На второй взгляд – тоже просто: примеры решения подобных задач имено так и сделаны. На третий взгляд – вообще всё замечательно: после компиляции код работает, документы выгружает. Ура.
Хуже на четвёртый взгляд, взгляд тестировщика – не выгружаецца! Целевая папка как бы недоступна… Нда… Модуль резервного копирования в ту же папку спокойно свои файлы сохраняет… При помощи отладчика можно наблюдать, как конструктор
new DirectoryInfo(path)
без выбрасывания каких-либо исключений возвращает непустой объект (что и ожидается), у которого свойство Exists == false. Сюрприз, фокус-покус.
Фокус разоблачается разглядыванием в Рефлекторе или IL-шпионе (ILSpy) кода классов из пространства Microsoft.SharePoint.Administration.Backup. Там методы System.IO используются примерно так:
using (SecurityContext.RevertToSelf())
{
info = new DirectoryInfo(dir);
}
Класс Microsoft.SharePoint.Utilities.SecurityContext почему-то “внутренний”, использовать как обычно его не получится, но для Reflection преград же нет… 
Значение ID из УРЛ страницы
В коде веб-части для получения значения параметра ID (да и любого другого) из УРЛа страницы, на которой веб-часть установлена, можно использовать LINQ-выражение:
1: ID = (from urlParameterName in this.Page.Request.QueryString.AllKeys
2: where urlParameterName.ToUpper() == "ID"
3: select this.Page.Request.QueryString[urlParameterName]).FirstOrDefault();
Оказывается – 5
… что и MSDN не всегда говорит правду.
Например, читаем
An expression using the &= assignment operator, such as
x &= y
is equivalent to
x = x & y
На практике оказывается, что эквивалентность для логических операндов наблюдается только в приведённом примере с константами:
class AndAssignment
{
static void Main()
{
bool b = true;
b &= false;
Console.WriteLine(b);
}
}
/*
Output:
False
*/
Если же операнд y является вызовом какой-либо процедуры, то оператор &= эту процедуру вызывает всегда, независимо от значения x.
.NET и Mono final-2
Всё же, финал получился какой-то неполный – так и неясно, как же эти программы, скомпилированные под Windows, работают в Linux под Mono последней версии 
. Пошарил по закромам, обнаружилась купленная когда-то за деньги 
(!!) версия Fedora Core, однако расследование показало, что с момента покупки прошло уже довольно много времени и эта моя версия больше не поддерживается. Пришлось качать актуальную, тем более, что вышла она меньше месяца назад, должно быть всё самое свежее.
Скачал Live CD (ок. 700 Мб), установил на диск (всё встало гладко и даже по-русски), подключилась системка к Сети и сразу же скачала 165 Мб. обновлений. Однако… И никакой последней версии Mono, естественно, на диске тоже не оказалось – ладно, не привыкать, скачал, поставил.
При запуске тестовой программки обнаружилось, что все ранее описанные неприятности пропали 
. Но, естественно, выявились новые – в TextBox и др. не вводятся с клавиатуры русские символы. Английские вводятся, при переключении раскладки – вовсе ничего не вводится 
. Хотя через clipboard можно и русские буквы всунуть. Какие-то тут сложные взаимодействия у них… Может, эта Fedora под Mono не приспособлена?
Осталось попробовать на SUSE – кому уж лучше быть приспособленной? Но очень уж дистрибутив здоровый у них…
.NET и Mono continued
Помрёт, похоже, этот мой эксперимент на гриде – элементах DataGrid или DataGridView. В принципе, они работают и в Linux (Ubuntu), кое-какие свойства глючат, но терпимо. Плохо, что не работает толком редактирование в ячейках, но обойти можно, хоть и будет это выглядеть чесанием левой ногой правого уха. Самое плохое с навигацией по гриду – на колесо мышиное не реагирует, а полосы прокрутки (scrolling) загружают процессор на 100% :
Нижний контрол на форме – DataGridView, зелёная линия справа – график загрузки процессора (скачок загрузки произошёл в момент изменения размеров формы до появления scrollbar’а на гриде).
В общем, для практики гриды применить не получится.
Слабо, правда, представляю деловые программы без гридов: прайс-лист соорудить, счёт выписать – везде гриды нужны. Привыкли все…
Осталось попробовать сделать интерфейс на ListView вместо грида – он, вроде, без фокусов с навигацией. Или делать программу в технике asp.net – говорят, эти программки переносятся хорошо (собственно, только они и переносятся).
Оставьте комментарий