Побитовые операторы | и & с аргументами типа bool в C#

Узнал сегодня следующую фишку: в C# операторы | и & можно использовать для аргументов bool. При этом они ведут себя не как побитовые операторы, а как обычные логические, но с одним отличием: всегда будут вычисляться оба аргумента. Это может быть удобно, когда второй аргумент является функцией (или свойством), возвращающей bool и делающей помимо этого ещё что-то полезное, и необходимо, чтобы она вызывалась всегда, даже если после вычисления первого аргумента значение логической операции И, либо ИЛИ уже ясно. При использовании обычных && и || второй аргумен вычисляется не всегда, например это не будет сделано в следующих случаях:

true || someFunc()
false && someFunc()

Под катом тестовый примерчик.

Url encoding средствами XSLT 1.0

Я уже писал в предыдущем посте, что пытался организовать Url encoding исключительно средствами чистого XSLT 1.0. Мне это удалось. Выглядит довольно криво, но вполне работоспособно. Подробнее под катом. О схеме кодирования нелатинских символов и спецсимволов в урле можно почитать в разделе "Кодирование URL" статьи об Url в Википедии.

Факториал на XSLT

Неожиданно сделал вычисление факториала средствами XSLT.

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

Шаблон sample иллюстрирует возможное использование (вычисляется 5! + 7!).

Разумеется, всё это довольно "игрушечные" вещи. В эту сторону меня потянула необходимость сделать url encoding в XSLT 1.0 для кириллических строк. Подумал, может удастся как-то рекурсивно откусывать от строки по символу и так производить перекодирование. Пока не сделал, это оказалось сильно сложнее, чем ожидалось.

Обычно для подобных задач задействуются внешние скрипты, но их не всегда можно использовать (например, в SharePoint скрипты msxsl по умолчанию выключены из соображений безопасности).

Внутренние имена полей SharePoint

Поля в SharePoint, как и некоторые другие сущности, имеют отображаемое имя и внутреннее имя. Они могут отличаться.
При создании поля через web-интерфейс мы задаём отображаемое имя, а проконтролировать, какое будет внутреннее имя не можем. Наибольшие проблемы тут возникают, когда при создании поле называют по-русски. При этом внутреннее имя поля будет сформировано автоматически и будет совершенно неудобоваримым.
Примеры:
DisplayName="Статус"            name="_x0421__x0442__x0430__x0442__x04"
DisplayName="Ё-моё! ;-)"        name="_x0401__x002d__x043c__x043e__x04"

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

Но, допустим, всё же есть поле, изначально имеющее кириллическое название. Как узнать его внутреннее имя, вот эту штуковину _x0421__x0442__x0430__x0442__x04?
К примеру, можно зайти на страничку изменения этого поля и посмотреть в адресной строке.
Идём в параметры списка, щёлкаем там на имени столбца (в случае, если управление типами контента для списка выключено, у него в параметрах будут отображаться все столбцы). Попадаем на страницу "Изменение столбца". Смотрим в адресную строку.
Там будет что-то вроде
http://yourservername/_layouts/FldEdit.aspx?List=%7BE8318722%2D3077%2D42C8%2D97C6%2D1364C9C804E1%7D&Field=%5Fx0412%5F%5Fx0020%5F%5Fx043f%5F%5Fx0440%5F%5Fx04
Нас интересует значение параметра Field. Берём его, заменяем %5F на подчёркивание (_) и в итоге получается внутреннее имя данного поля.