Действия (Actions) в страницах NAV 2009 (часть 2).
Итак, долгожданное продолжение статьи . Это как многие догадались шутка, т.к. первая часть статье вышла в этом же номере.
Ну что ж. Перейдем к делу, точнее к действиям. В предыдущей части мы рассмотрели действия, которые находятся в меню Actions, Related Information и Reports. Также мы узнали, как создавать действия на панели действий. Кроме того познакомились с новой возможностью, появившейся в NAV 2009 SP1, которая позволяет программно создавать новые категории в панели действий.
Как помним, для создания действий мы использовали Action Designer. Как мы выяснили любое действие должно находиться в своеобразном контейнере, т.е. принадлежать элементу типа ActionContainer. Контейнеры бывают шести типов, четыре из которых мы рассмотрели в предыдущей статье. В данной статье мы рассмотрим оставшиеся два типа контейнеров и влияние, которое они оказывают на систему. К оставшимся двум типам контейнером относятся HomeItems и ActivityButtons.
Как уже было сказано в предыдущей статье, контейнеры HomeItems и ActivityButtons могут использоваться только в страницах типа RoleCenter. Нельзя не отметить, что при этом в страницах типа RoleCenter нельзя использовать контейнеры RelatedInformation и NewDocument.
Примечание. Создать контейнеры RelatedInformation и NewDocument в страницах типа Role Center можно, но они на экране не отображаются.
HomeItems
Данный контейнер содержит действия, которые в ролевом центре отражаются как элементы в меню Home. Для примера, рассмотрим действия, заданные для ролевого центра Order Processor (page 9006 Order Processor Role Center).
А теперь взглянем на сам ролевой центр в ролеориентированном клиенте.
Даже невооруженным глазом видно две особенности:
- В окне Action Designer в контейнере HomeItems нет элементов типа ActionGroup. Однако в самом меню Home есть вложенные элементы.
- В меню Home элементов намного больше, чем в контейнере HomeItems. Откуда взялись остальные элементы?
Система сама управляет вложенностью элементов. Если присмотреться, то можно заметить, что под элементом Sales Order, при нажатии на который открывается страница Sales Orders, сгруппированы элементы, которые тоже ссылаются на страницу Sales Orders. Т.е. система при обработке списка действий находит первый элемент, который ссылается на некий объект и отображает его на первом уровне. Если при последующей обработке списка действий система встречает еще элементы, которые ссылаются на тот же объект (независимо от их положения в списке действий), то она подчиняет их первому элементу.
Например, у страницы 9006 Order Processor Role Center в контейнере HomeItem первым идет элемент Sales Orders, который ссылается на страницу Sales Orders List (свойство RunObject = Page Sales Order List). Этот элемент помещается на первый уровень. Следом идет элемент Shipped Not Invoiced, который тоже ссылается на страницу Sales Orders List. Его система помещает на второй уровень, относительно Sales Orders.
Теперь вернемся к непонятно откуда взявшимся действиям. На самом деле эти действия пришли из веб-части Activities. На ней данные действия выглядят в виде стопок документов. На следующем рисунке показана связь между элементами меню Home и веб-части Activities.
При определении подчиненности для элементов, перенесенных из веб-части Activities, действуют те же правила. Т.е. если данные элементы ссылается на объект, на который уже есть ссылки в меню, то этот элемент помещается на второй уровень. А если элемент ссылается на объект, на который ссылок в меню еще не было, то этот элемент помещается системой на первый уровень.
Вопрос: зачем система вообще создает элементы меню на основании элементов из веб-части Activities?
Ответ: На веб-части Activities расположены наиболее часто используемые элементы. Это значит, что для их открытия нужно затрачивать как можно меньше усилий. Система дублирует эти элементы в меню Home, таким образом, чтобы открыть наиболее часто используемую страницу (например, Ready to ship) пользователю нужно щелкнуть всего лишь один раз мышкой, даже если он находится не в ролевом центре, а в списке клиентов (Customers) или товарном журнале (Item Journals).
ActivityButtons
Может случиться так, что пользователь выполняет много различных задач в системе, одни чаще, другие реже. Чтобы пользователь мог переходить на соответствующие страницы нужно создать в ролевом центре много элементов меню. Однако меню Home не предоставляет возможностей для структуризации. Значит ли это, что при проектировании системы была допущена ошибка? Ответ – нет. Для структуризации элементов меню используется другой способ – создание дополнительных меню.
Именно для этих целей используется контейнер ActivityButtons. Элементы, находящиеся в этом контейнере, помещаются в меню, расположенные между меню Home и меню Departments.
В отличие от контейнера HomeItems, в контейнере ActivityButtons присутствуют элементы типа ActionGroup. Более того они играют важную роль - они и есть меню, которые располагаются между меню Home и меню Departments.
Итак, мы рассмотрели действия, которые задаются для страницы в целом. Однако существуют действия, которые задаются для части страницы.
В качестве примера рассмотрим все тот же ролевой центр Order Processor, а точнее его элемент – веб-часть Activities.
1. Откройте страницу 9060 SO Processor Activities в Page Designer.
2. Установите курсор во вторую строку -
В окне Action Designer будут представлены действия, связанные с данной группой:
Обратите внимание, что в данном случае действиям ни в какие контейнеры не помещаются, в данном случае в роли контейнера выступает группа, к которой привязаны действия.
Примечание: Действия можно привязывать либо к странице в целом (для этого надо установить курсор в пустую строку Page Designer), либо к группе подтипа Group или CueGroup.
Строка
Если же добавить действия группе подтипа Group, то в ролеориентированном клиенте эти действия будут отображаться при нажатии на кнопку Action (в виде молнии):
На этом завершим обзор новых сущностей под названием действия (Actions).
Метки: Андрей Панько
