29.04.2012, 00:14 | #1 |
Участник
|
axforum blogs: Xrm.Page Controls vs Attributes
Источник: http://axforum.info/forums/blog.php?b=332
============== Временами, роясь в SDK по CRM 2011 я не без грусти вспоминаю времена CRM 3.0... Больше всего я грущу даже не по быстродействию системы и не ее скромных запросах к железу, а собственно по SDK. SDK по "тройке" читался как детектив! Всегда было интересно начать новый раздел, так как мысль выдавалась последовательно. В новой версии SDK сломит ногу сам черт! За какую тему вы бы не взялись: кастомизация, плагины или скрипты - она обязательно будет разбита на два-три раздела! В одной куче лежит только традиционно краткий мануал по отчетности. Собрать картину воедино в таких условиях непросто. Немудрено упустить что-то нужное, если не знать точно что ищешь. Но все это лирика! О чем собственно пост? Пост о изменениях в объектной модели CRM формы. Изменения отчасти навеяны тем, что в прошлых версиях модели не было как таковой, отчасти большим количеством нововведений. В этом посте мы поговорим о двух семействах элементов - Контролы (Controls) и Атрибуты (Attributes) которые, по своей сути, отражают одно и то же - старые добрые Поля (Fields) формы в 3.0/4.0. Атрибуты наиболее похожи на Поля из прошлых версий системы. От них можно получить значение, можно узнать тип и размер поля. Методы и свойства, как и раньше зависят от типа. Лукап представляет собой сложный объект, число или дата - примитивный тип JScript. Коллекция атрибутов доступна по простому и краткому мнемоническому пути: Код: Xrm.Page.data.entity.attributes Положительным отличием от 3.0 и 4.0 является то, что в этой коллекции лежат только объекты CRM а не весь документ, как это было раньше. Контролы представляют визуальное отражение атрибутов. У них есть метка (Label), видимость, активность или фокус на форме. Контролы доступны по еще более простому пути, нежели атрибуты: Код: Xrm.Page.ui.controls К счастью для обеих коллекций разработчики предусмотрели действительно короткие ярлыки: Код: Xrm.Page.getAttribute()Xrm.Page.getControl() В чем суть, почему коллекций две и зачем потребовалось столь спорное, в некоторых случаях, разделение методов по работе с полями? Все просто: в общем случае количество элементов в этих коллекциях может не совпадать. Проще говоря, одно и то же поля может быть помещено на форму в несколько мест. В этом случае полю будет соответствовать один атрибут и несколько контролов. В чем издевка? Функция getControl(), равно как и исходная ui.controls.get(), по имени поля всегда возвращает один контрол! Дело в том, что только первое добавленное на форму поле получает имя как у атрибута, например "name". Все последующие будут называться "name1", "name2" и т.д. Почему нельзя было возвращать массив, как, например, из лукапа, лично я не понимаю. Так как с этим жить, если пользователь пронюхал, что поле может быть на форме дважды и теперь и без того хитрый скрипт, которым приходилось работать с обоими семействами придется дополнить, чтобы учесть специфику? Ответ так же прост: к счастью, коллекции связанны между собой не только именами элементов. Каждый контрол ссылается на исходный атрибут, который он представляет. И что даже более важно, каждый атрибут ссылается на коллекцию связанных с ним контролов. Последняя связь настолько криво документирована в текущей версии SDK (Version 5.0.10, March 2012): Цитата: The attribute object provides methods to retrieve information and perform actions on attributes. It also contains a Controls Collection. что понять, что есть связь и как ей пользоваться можно только отладчиком! Получение атрибута из контрола: Код: control.getAttribute() Получение контролов из атрибута: Код: attribute.controls[0]attribute.controls.get() При этом сигнатура функции get() такая же как у функции для общей коллекции. Поддерживаемая это опция или нет - черт его знает. Думаю что да. В любом случае, она как минимум удобная! Удачного скриптинга! Источник: http://axforum.info/forums/blog.php?b=332
__________________
Расскажите о новых и интересных блогах по Microsoft Dynamics, напишите личное сообщение администратору. |
|
|
|