вторник, 18 октября 2011 г.

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

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

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

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

Intellisense

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


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



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


Отладка

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

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

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

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

НО!

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

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

Итог

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

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

2 комментария:

  1. Да, отладка xslt для шарика это что то, сам убил дня два на приемлемый путь отладки.
    в итоге после разного рода страданий:
    1. Делаем все в VS , но
    a. файл xslt напрямую сохраняем в библиотеки шарика через WebDAV
    b. Соответственно отлаживаемая веб-часть использует нашу xslt
    c. В итоге: изменили, сохранили, рефреш страницы сделали, посмотрели.
    d. Примечание: сохранение в hive требует доп. действий по обновлению веб-части, что бы она стала реагировать но обновленный файл xslt,а это не удобно, надоедает.
    2. SPD - на тестовой вьюшке "творим" нужные intellisense, ручками переносим в VS
    a. В SPD что то делать надо иметь не дюжее терпение, и постоянно под стрессом, что все может накрыться "пиз...", ибо SPD это просто шедевр индуского сопля строения.
    3. Разработали специальный шаблон GetXML что бы дампить значения.
    4. Как таковой отладки по сути то и нет. По факту изменил, применил, посмотрел результат и это очень печально.

    ОтветитьУдалить
  2. Вдогонку к пункту 3
    Шаблон GetXML возвращает два xml фрагмента:
    a. в первом dsQueryResponse\rows + специально вставленная внутрь ноды dsQueryResponse\view
    b. во втором заполненные xsl:param из maim.xsl
    Полученные xml в последствии можно использовать при отладке в VS, на ура.
    Но, к сожалению, при условии использования ddwrt: и такой подход тоже бесполезен.

    ОтветитьУдалить

Внимание! Реклама и прочий спам будут беспощадно удаляться.