понедельник, 26 августа 2013 г.

CamlJs 2.0

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

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

Зачем нужен CamlJs


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



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

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


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

понедельник, 19 августа 2013 г.

Про TypeScript и Unit-test'ы

Недавно для своего 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, я на неё поздновато наткнулся, но алгоритм там более подходящий для моих целей, и библиотека сама очень развитая.

Выводы

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

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

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

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

пятница, 16 августа 2013 г.

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

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

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

  1. Изъят мощнейший инструмент для разработки XSLT - SharePoint Designer. Точнее, изъята та его часть, которая относилась к генерации XSLT. Кое-что можно по-прежнему выжать из местами оставшихся кнопок на Ribbon в Code View, но даже для простейших представлений код веб-частей генерируется нередко нерабочий. Иными словами, это уже неподдерживаемый функционал, которым пользоваться нереально.
  2. XSLT-преобразования очевидно уже стоят в низком приоритете для команды тестирования SharePoint. Как следствие - уже сейчас, в SP2013, начинают накапливаться баги, связанные с работой XSLT. Пример: в js, который используется для свертывания/развертывания групп при наличии группировки в DataFormWebPart - в SP2013 содержит ошибку. Т.е. группировку в этой веб-части невозможно использовать "OOTB", придется этот баг исправлять подменяя SharePoint'овскую js-функцию. Я наткнулся на этот баг, когда пытался мигрировать свой английский блог, который у меня сделан на SharePoint 2010 :(
  3. Представлен концептуально новый подход к отображению данных (Client Side Rendering ака CSR), и сейчас ни одна веб-часть в SharePoint по умолчанию более НЕ использует XSLT преобразования. Все списки показываются с помощью CSR, и результаты поиска - тоже.
  4. 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:
  1. Разбиение формы на вкладки
  2. Lookup-поле с автокомплитом, работающим по данным поиска
  3. Кастомная валидация полей формы списка
  4. "Color coding" на CSR
  5. Custom Field на CSR (пример сделан на основе того что есть на MSDN, но внутри код гораздо более правильный и понятный)
  6. Custom List View (очень простой пример из серии "как начать")
Все эти примеры, хотя написаны на TypeScript, доступны параллельно еще и на JS. И к слову, TypeScript генерирует очень даже читабельный код, честно, я сам был удивлен :) Так что даже если вы не планируете использовать TypeScript, но решили использовать CSR - эти примеры вам могут помочь понять, как оно работает, и избежать многочисленных граблей, которые традиционно присутствуют в ошеломляющих количествах :)

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

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

понедельник, 5 августа 2013 г.

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

В прошлый раз я теоретизировал о необходимости знаний по 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.

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

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


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

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

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

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


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

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

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

Выводы

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

пятница, 2 августа 2013 г.

Usability и UX в SharePoint

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

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

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