Xrm.Page Controls vs Attributes

Временами, роясь в SDK по CRM 2011 я не без грусти вспоминаю времена CRM 3.0... Больше всего я грущу даже не по быстродействию системы и не ее скромных запросах к железу, а собственно по SDK. SDK по "тройке" читался как детектив! Всегда было интересно начать новый раздел, так как мысль выдавалась последовательно. В новой версии SDK сломит ногу сам черт! За какую тему вы бы не взялись: кастомизация, плагины или скрипты - она обязательно будет разбита на два-три раздела! В одной куче лежит только традиционно краткий мануал по отчетности.

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

Но все это лирика! О чем собственно пост? Пост о изменениях в объектной модели CRM формы. Изменения отчасти навеяны тем, что в прошлых версиях модели не было как таковой, отчасти большим количеством нововведений. В этом посте мы поговорим о двух семействах элементов - Контролы (Controls) и Атрибуты (Attributes) которые, по своей сути, отражают одно и то же - старые добрые Поля (Fields) формы в 3.0/4.0.

Атрибуты наиболее похожи на Поля из прошлых версий системы. От них можно получить значение, можно узнать тип и размер поля. Методы и свойства, как и раньше зависят от типа. Лукап представляет собой сложный объект, число или дата - примитивный тип JScript.

Коллекция атрибутов доступна по простому и краткому мнемоническому пути:
Положительным отличием от 3.0 и 4.0 является то, что в этой коллекции лежат только объекты CRM а не весь документ, как это было раньше.

Контролы представляют визуальное отражение атрибутов. У них есть метка (Label), видимость, активность, или фокус на форме.

Контролы доступны по еще более простому пути, нежели атрибуты:
К счастью для обеих коллекций разработчики предусмотрели действительно короткие ярлыки:
В чем суть, почему коллекций две и зачем потребовалось столь спорное, в некоторых случаях, разделение методов по работе с полями?

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

В чем издевка? Функция getControl(), равно как и исходная ui.controls.get(), всегда возвращает один контрол по имени поля! Дело в том, что только первое добавленное на форму поле получает имя как у атрибута, например "name". Все последующие будут называться "name1", "name2" и т.д. Почему нельзя было возвращать массив, как, например, из лукапа, лично я не понимаю.

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

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

Последняя связь настолько криво документирована в текущей версии SDK (Version 5.0.10, March 2012):что понять, что есть связь и как ей пользоваться можно только отладчиком!

Получение атрибута из контрола:
Получение контролов из атрибута:
При этом сигнатура функции get() такая же как у функции для общей коллекции.

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