Прикладные действия. Примеры и особенности использования

13 4

Ранее в статье о прикладных действиях, появившихся в версии DIRECTUM 5.2 уже рассказывалось о том, какие возможности дает новый функционал. В этой статье хотелось бы акцентировать внимание на примерах и особенностях разработки прикладных действий.

Особенности работы через форму-список справочника

В большинстве случаев необходимые для работы Действия в справочнике уже разработаны и активно используются с формы-карточки. Что же необходимо для того, чтобы они начали работать с формы списка?

Во-первых необходимо добавить Действие на ленту формы-списка.

Во-вторых необходимо действие адаптировать под работу из списка. Из-за того, что при работе со списком карточка записи справочника не открыта, необходимо сделать это в самом действии:

  RecordOpened = Object.RecordOpened
  View = Object.View
  if not RecordOpened
    Record = References.<Справочник>.GetObjectByID(View.SelectedRecordsID(0))
    Record.OpenRecord
  endif

При необходимости действие можно вынести и в контекстное меню. Это делается легко и удобно в один клик, но тоже имеет свою особенность. Наименование и иконка пункта контекстного меню будут именно такие, какие заданы в редакторе действий и менять их можно только там.

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

  1. Вынесенное на форму-список действие желательно должно присутствовать и на форме-карточке
  2. Иконки должны отражать смысл прикладных действий и быть интуитивно понятными
  3. В контекстное меню желательно выносить только наиболее приоритетные действия, чтобы не загромождать его
  4. Наименования и иконки действия на лете формы-списка, формы-карточки и в контекстном меню должны быть одинаковыми

Особенности разработки ПД при множественном выборе

Если необходимо в цикле обработать несколько выделенных записей, то используется метод SelectedRecordCount.

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

  1. Если при вызове прикладного действия запрашиваются какие-либо данные, то по возможности запрашивать их один раз (над циклом по записям), если же для каждой из строк данные нужны разные, то не использовать множественный выбор, так как слишком много однотипных подряд идущих диалоговых окон будут неудобны для пользователя.
  2. Для удобства пользователи можно добавить прогресс-бар, который покажет сколько строк на данный момент обработано.

Рассмотрим пример реализации действия для множественного с учетом всего ранее сказанного:

  // Выяснить, открыта ли запись справочника. Если нет – работа идет из формы-списка
  RecordOpened = Object.RecordOpened
  View = Object.View
  CardCount = View.SelectedRecordCount
  i = 0
  // Показать индикатор, если действие вызывается из формы-списка
  if not RecordOpened
    Progress = CreateProgress('Изменение значений полей'; CardCount)
    Progress.Show
  endif

  while i <= CardCount - 1
    // Открыть запись, если действие вызывается из формы-списка
    if not RecordOpened
      Record = References.<Справочник>.GetObjectByID(View.SelectedRecordsID(i))
      Record.OpenRecord
    else
      Record = Object 
    endif    

    <Действия над записью справочника>
  
    // Закрыть запись и увеличить индикатор
    if not RecordOpened
      Record.CloseRecord
      Progress.Next
    endif
    i = i + 1
  endwhile

  if not RecordOpened
    Progress.Hide
  endif

Замена вариантов выполнения на прикладные действия

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

  Object.Form.PerformWithResult('Согласовано')

При работе через метод PerformWithResult объекта IForm производятся все проверки, которые должны осуществляться при выполнении задания с таким результатом. При работе же через PerformWithResult объекта IJob проверки производиться не будут.

Для замены вариантов выполнения на прикладные действия тоже хотелось бы дать несколько рекомендаций:

  1. Для того, чтобы пользователи не путались, наименования вариантов выполнения должна совпадать с наименованиями кнопок на ленте. Наименования вариантов выполнения появляются при выполнении задания в режиме предпросмотра
  2. Удобно вынести единственный вариант выполнения кнопкой большого размера в том случае, если имеет смысл дать смысловое наименование вместо нейтрального «Выполнить».
  3. Имеет смысл вынести две большие кнопки для двух противоположных наименований (Например, «Согласовано»/«На доработку»), либо трех-четырех вариантов, среди которых можно выделить наиболее часто используемый вариант и сделать его большой кнопкой, остальные – кнопками маленького размера.
  4. Не рекомендуется загромождать ленту большим количеством вариантов.
  5. Иконки вариантов выполнения должны отражать их суть.
Алексей Семакин
При работе через метод PerformWithResult объекта IForm производятся все проверки, которые должны осуществляться при выполнении задания с таким результатом. При работе же через PerformWithResult объекта IJob проверки производиться не будут.

Ксюша, какие проверки ты имеешь в виду?

Ксения Иванова
Ксюша, какие проверки ты имеешь в виду?

Выдержка из справки:

Метод выполняет задание с результатом PerformResult. В отличие от метода IJob.PerformWithResult при выполнении задания с помощью метода IJobForm.PerformWithResult:

корректно обрабатывается обновление карточки;
выполняется запрос на выдачу прав на вложения;
запрашивается подтверждения на выполнение задания.
Сергей Камышев

А еще проверяется орфография, если пользователь включил это в настройках.

Анна Долганова
Вынесенное на форму-список действие желательно должно присутствовать и на форме-карточке

Лишняя рекомендация. Например, если действие не работает с записью напрямую (кнопка Настройки в карточке РКК) или изменяет набор данных (своя фильтрация) - то действие в карточке будет лишь бессмысленно перегружать интерфейс записи.

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

Авторизуйтесь, чтобы написать комментарий