![]() |
#1 |
Участник
|
axforum blogs: Разбираемся с лентой (Ribbon)
Источник: http://axforum.info/forums/blog.php?b=310
============== На просторах Инета достаточно много описаний, как вставить кастомную кнопку на ленту. Вот, например, несколько ссылок: http://gtcrm.wordpress.com/2011/01/1...-in-crm-2011-3 http://blog.tallan.com/2011/06/24/mi...rom-the-ribbon http://dynamicscrm2011.wordpress.com...-customization Ниже речь пойдет о расширенном функционале, позволяющем не только вставить кнопку (или любой другой разрешенный элемент) на ленту, но и «оживить» ее: определив дополнительные правила, когда эта кнопка видна, когда скрыта или когда запрещено нажатие. Детальное описание поведения ленты можно подчерпнуть из библиотеки MSDN, зайдя в раздел Ribbon XML Refference. Описание ниже – для ленивых :) Итак, предположим, что определение кастомной кнопки либо другого какого интерфейсного элемента на ленте уже задано в файле customizations.xml. Все наши правки файла customizations.xml будут затрагивать раздел — корневой узел для всех кастомных элементов. Он содержит 5 вложенных разделов:
X++: Стоит также прислушаться к рекомендациям Microsoft об именовании идентификаторов. Соглашение об именовании MSDN требует использовать следующее правило: X++: [solution identifier].[entity].[ribbon].[function].[element name] Получится что-то вроде этого: X++: Общее правило редактирования описания ленты в файле customizations.xml звучит следующим образом: опиши ВСЕ необходимые правила в разделе , затем в разделе укажи, КАКИЕ ПРАВИЛА ДЛЯ КАКИХ ЭЛЕМЕНТОВ ленты должны применяться. Чтобы правило в привязать к команде в , используется уникальный идентификатор правила. Таким образом, для каждого элемента на ленте мы можем задать несколько правил видимости / доступности и несколько действий (actions). А чтобы различать эти плавила и действия –используются уникальные идентификаторы (не путать с идентификаторами самих элементов на ленте!). Что нам нужно для элементов на ленте?
X++: где разделы, или группы правил, , будут раскрыты более детально ниже. Из наименований разделов видно, что они представляют собой коллекции, а значит, содержат элементы с соответствующими названиями. Коллекция будет содержать элементы и т.п. Таким образом, схема нашей работы будет выглядеть следующим образом: X++: Задать идентификаторы для каждого элемента в Указать идентификаторы используемых правил в разделах , , для каждого правила и каждого действия (т.е. сослаться на правила, используя идентификаторы правил). Задать идентификаторы правил и действий в разделах , , Описать сами правила и действия. Не допускается ссылки на несуществующее правила. Т.е. если определение правила удалено из , то все ссылки на него должны быть удалены и из . С объявлениями правил и действий все понятно, разберемся с определениями (описаниями). Группы правил и Синтаксис описания групп правил идентичен: X++: … … X++: … … Полный список правил приведен ниже. Правило / Раздел CrmClientTypeRule + + CrmOfflineAccessStateRule + + CrmOutlookClientTypeRule + + CrmOutlookClientVersionRule – + CustomRule + – EntityPrivilegeRule – + EntityPropertyRule – + EntityRule + + FormEntityContextRule – + FormStateRule + + MiscellaneousPrivilegeRule – + OrganizationSettingRule – + OrRule + + OutlookItemTrackingRule + – OutlookRenderTypeRule – + OutlookVersionRule + + PageRule + + RecordPrivilegeRule + – ReferencingAttributeRequiredRule – + RelationshipTypeRule – + SelectionCountRule + – SkuRule + + ValueRule + + Детальное описание того, как и какие правила можно определять, содержится в библиотеке MSDN. Рассмотрим только несколько наиболее привлекательных. (применимо только в ) Задает вызов функции JavaScript из библиотеки функций. Должны быть обязательно указаны имя функции и имя библиотеки. CRM самостоятельно производит вызов функции, указанной в , в следующих случаях:
Описание правила можно расширить несколькими опциональными полезными вещами.
X++: Для определения состояния элемента на ленте вызывается функция Gl.Quote.ApprovalCommand из библиотеки Gl_Quote_Library пользовательского JavaScript кода. Возвращаемое функцией булево значение инвертируется (потому что InvertResult="1"). До момента первого вызова функции или при ошибке вызова функции элемент считается разрешенным (потому что Default="true"). Примечание:
Задает состояние элемента в зависимости от состояния формы. Должно быть обязательно указано состояние формы State, при котором элемент на ленте будет разрешен/видим или запрещен/невидим. Опциональный атрибут Default определяет состояние элемента в случае, когда состояние формы определить не удается (даже не представляю, когда такое может быть). Опциональный атрибут InvertResult=«1» инвертирует результат применения правила. Вы можете указать следующие состояния формы, на которые будет реагировать элемент:
X++: Элемент на ленте будет разрешен/видим для всех состояний формы, кроме Create (т.е. после того, как новая запись будет сохранена). Задает состояние элемента в зависимости от значения поля на форме. Должны быть обязательно указаны имя поля и отслеживаемое значение. Правило звучит следующим образом: задать состояние элемента, как только в указанном поле будет установлено указанное значение и запись будет сохранена. Как и прежде, атрибут InvertResult инвертирует действие правила. Это означает, что если мы хотим, чтобы элемент на ленте был разрешен/видим во всех случаях, кроме случая, когда в поле Field присутствует значение Value, то мы должны использовать InvertResult=«true». Опциональный атрибут Default определяет состояние элемента в том случае, когда значение поля не определено, т.е. отсутствует (null). Пример: X++: Разрешить/показать элемент, когда в наборе параметров PriceCode будет выбрана строка, имеющая значение 2. Вы можете использовать строковое поле или числовое поле, а не только набор параметров. Заметьте, что правило сработает не тогда, когда вы введете ключевое значение в отслеживаемое поле (и покинете его), а только после сохранения записи. (применимо только в ) Задает видимость или невидимость элемента в зависимости от свойств сущности. В правиле должны быть обязательно указаны:
Необходимо использовать AppliesTo=”PrimaryEntity” для элементов на главной ленте формы сущности и AppliesTo=”SelectedEntity” для элементов на ленте грида; причем будут проверяться свойства не самой сущности, содержащей грид, а свойства выбранных сущностей в гриде. Соответственно, применение в правиле опционального атрибута EntityName уместно для случая, когда AppliesTo=”SelectedEntity”, и грид может содержать разные типы сущностей (например, разные Activities). Как и раньше, опциональные атрибуты Default и InvertResult определяют значение по умолчанию и требование инвертирования результата применения правила. С помощью правила можно контролировать наличие следующих свойств у сущности:
Пример: X++: Показать элемент на ленте формы, если сущность может быть связана с Действиями (т.е. Действие может ссылаться на сущность в поле В отношении). (применимо только в ) Задает видимость или невидимость элемента в зависимости от полномочий пользователя по отношению к заданной сущности. В правиле должны быть обязательно указаны:
Как и раньше, Default задает состояние элемента по умолчанию, когда невозможно определить обязательные параметры правила (привилегии и уровень доступа), а InvertValue инвертирует значения указанных параметров (привилегии и уровень доступа наоборот). Опционально можно указать логическое имя сущности, к которой будет применяться это правило, в атрибуте EntityName. Также можно указать, к какому типу записей данное правило относится: к главной форме или к записям в гриде. В первом случае используем AppliesTo=«PrimaryEntity», во втором — AppliesTo=«SelectedEntity». Пример: X++: Показать элемент, если пользователь имеет привилегии на уровне подразделения и имеет право редактировать запись. Источник: http://axforum.info/forums/blog.php?b=310
__________________
Расскажите о новых и интересных блогах по Microsoft Dynamics, напишите личное сообщение администратору. |
|
|
|