Оглавление
MVC
Впервые с проблемой реализации интерфейса я столкнулся на собеседовании. У меня был выпускной год, а это начало 2000-х, тогда большой популярностью пользовались такие среды разработки как Delphi, Visual FoxPro. На собеседовании мне нужно было предложить алгоритм обновления интерфейсной формы, реализованной в текстовом формате. Представьте, что вы разработчик командного навигатора far и вам нужно решить проблему быстрого отображения окон навигатора, а также изменений в нем. Вот курсором подсвечено имя файла, вот вы передвинули курсор и: обновилась информация о файле, прежнее имя файла стало обычным, а новое - выделенным и т.д.
Предложенное мной решение не удовлетворило интервьюера. Я тогда уже имел некоторый опыт программирования графических систем и умел работать с буферизацией графической памяти. Мое решение заключалось в полном рендеринге формы в память с последующим отображением на экране.
В основе моего подхода лежал простой принцип: решить задачу отображения текущего состояния системы легче, чем рассчитать переход из прежнего состояния в текущее. Решение же проблемы возникновения лагов при рендеринге можно решить буферизацией изображения.
В ту компанию я не попал, однако я стал программистом 1С. В мире 1С все решалось на порядки проще, особенно при создании интерфейсов, чем в языках общего назначения. Однако, как ни странно, проблема рендеринга осталась по прежнему актуальной и здесь. Конечно от нас не требуется делать многое из того, что делается самой платформой. В нашем распоряжении множество интерфейсных элементов, которые сами прекрасно справляются со своим рендерингом. А в режиме управляемого интерфейса появилось еще больше возможностей: элементы сами подстраиваются под экран, есть возможность декларативной настройки.
Когда бизнес-логика предполагает нечто большее, чем просто вывести текущее значение из данных объекта на экран или изменение в данных опосредовано, то возникает необходимость изменить стандартное поведение платформы. 1С - это событийно-ориентированная система, в которой изменить стандартное поведение платформы можно в точках расширения - предопределенных событиях на встроенном языке, таких как: ПриСозданииНаСервере, ПриОткрытии, ПриИзменении, ПриНажатии и т.д.
Простым решением для обновления формы является использование единой процедуры, которая выполняет полную настройку элементов формы. В некоторых решениях таких функций может быть несколько и выбор одной из них определяется местом и характером изменений в данных. Использование отдельных функций обновления оптимизирует выполнение настройки формы, но также усложняет решение.
Поиск путей оптимизации и упрощения реализации алгоритмов работы с формой привел меня к созданию фреймворка «Управление состоянием». Основная концепция фреймворка лежит в области понимания идеи MVC.
Внешнее представление формы является отражением внутреннего состояния объекта предметной области. Интерфейс при этом выполняет две задачи: предоставляет средства ввода и отображает текущее состояние модели данных. Однако изменение данных может производится не только из формы, но и через программный интерфейс.
Последнее обстоятельство предполагает такое решение, где бы код по изменению данных находился вне модуля формы, ведь при программном вызове форма не нужна. Именно здесь и возникает выделение программного слоя модели объекта от программного слоя интерфейса.
Выделение же программных слоев контроллера и представления уже не выглядят столь очевидно. Здесь идея архитектурного решения заключается в выделении программного слоя по трансляции изменений в модель из полей интерфейса и слоя отображения формы для текущего состояния данных. Теоретически такое разделение позволит комбинировать один и тот же контроллер под разные формы или переиспользовать представления для разных моделей данных. Впрочем, практическое воплощение такой идеи я пока не встречал в решениях на 1С.
Разделение кода на программные слои позволяет добиться независимости использования каждого из них, а также использовать их комбинации. Такое разделение позволяет отдельно тестировать код, ответственный за трансляцию изменений в данные модели, расчет модели и ответственный за рендеринг.
Трансляция изменений в данные осуществляется в событиях ПриИзменении, ПриНажатии и других.
Далее уже алгоритмы модели ответственны для перехода данных в новое состояние.
Рендеринг осуществляется уже после изменений в данных модели. Алгоритм реализации рендеринга можно переиспользовать в разных формах, где есть подобные интерфейсные решения.
Состояние модели – это вся совокупность параметров и их значений в любой момент времени. Состояние формы является отражением состояния модели. Последнее означает, что настройка формы точно соответствует состоянию модели.
В контексте решаемой задачи отображения формы нас не интересует как система перешла в данное состояние, однако нам необходим алгоритм однозначной интерпретации состояния в любой момент времени. Именно этой интерпретацией и занимаются функции состояния. Для каждого элемента формы определяется своя функция состояния, для которой определен свой набор параметров модели.
Функция состояния является чистой в том смысле, что она детерминирована входящими параметрами, не имеет внешнего влияния и побочных эффектов (если не считать передаваемую в функцию структуру свойств элемента, которая заполняется внутри функции и является результатом ее работы). Такие функции обладают рядом ключевых достоинств:
- Их просто тестировать. Достаточно передать в функцию нужные параметры и получить ожидаемый результат
- Их безопасно запускать повторно. Такие функции хорошо работают в асинхронном или многопоточном коде
- Их легко комбинировать, получая новое поведение без необходимости переписывать программу
Обычно под моделью предполагают код, ответственный за работу с данными объекта. А если форма имеет собственное состояние, не отраженное в модели объекта? Состояние формы может быть выведено из данных модели, а может иметь и собственное внутреннее сохраняемое состояние.
Собственное состояние формы приводит к необходимости с ним работать. Здесь ситуация аналогична той, что и при изменениях в объекте, только в роли объекта выступает сама форма. Т.е. реализация работы с самой формой также может описываться архитектурным решением на базе MVC: контроллер изменяет данные формы, модель работает с данными, представление – реализует рендеринг.
Архитектурное решение MVC получается применимо не только на уровне интерфейса и его взаимодействия с объектом, но и на уровне реализации работы самого интерфейса, если он также имеет собственное состояние. Это обстоятельство важно в свете понимания реализации поведения интерфейса в связке с объектом модели или без него.
Платформа 1С, как уже упоминалось ранее, вполне сама справляется с задачей отображения данных на форме. Если отображение предполагает свою логику, как то, какие элементы формы будут показаны или как будут оформлены, то для этого можно использовать механизм условного оформления.
Условное оформление позволяет описать настройку элементов формы в зависимости от условий. Для настройки оформления отдельных строк таблицы формы механизм условного оформления является единственным возможным способом повлиять на оформление ячеек строк таблицы. Что касается остальных элементов, не относящихся к полям таблицы, то здесь возможности условного оформления очень скромные и слабо документированные. Более того, похоже, что набор параметров, доступных в условном оформлении, взят именно из набора для оформления ячеек таблицы и потому отражает далеко неполную часть параметров реально доступных для настройки оформления других элементов формы.
Получается, если нужно настроить отдельные ячейки таблицы формы, то единственный возможный вариант - использовать условное оформление. Для настройки остальных элементов формы потребуется программная реализация в точках расширения - предопределенных событиях формы.
Рисунок 1. Параметры условного оформления и свойства элемента формы
Рассмотрим простой пример формирования сводной информации по налоговым реквизитам. В этом примере информационная надпись формируется в заголовке группы налоговых реквизитов, например, таких: код ОКАТО, код БК, статуса составителя, идентификатора платежа, различные показатели (основания, периода, номера, даты). В нашем примере мы ограничимся только этими реквизитами, однако в реальной системе реквизитов может быть гораздо больше, а их связи разнообразнее.
В формировании надписи на форме в общем то нет ничего сложного. Действительно, что может быть проще кода, который собирает строку из данных для вывода информации в форматированном виде? Однако дело здесь не в самом выводе, а в связях источников информации.
Связи источников позволяют системе делать обновления по событиям изменения данных. Для разных надписей могут быть различные множества источников. Каждый раз, когда в одном из источников происходит изменение данных, система определяет какие параметры состояния изменились? Какие элементы формы должны быть обновлены?
В этом примере форма не имеет собственного состояния и слой модели не требуется реализовывать. Все что здесь требуется – определить функцию состояния элемента свертываемой группы, в заголовке которой формируется информационная надпись. Для настройки свяжем элемент группы «НалоговыеРеквизиты» с функцией состояния и входящими параметрами.
Запустим тестовую обработку "Налоговые реквизиты". Убедимся, что надпись изменяется при изменении налоговых реквизитов.
Рисунок 2. Модуль формы. Настройка элемента формы группы
Рисунок 3. Форма и функция состояния для элемента формы
Еще одним примером, в котором не требуется реализовывать контроллер, является реализация заголовка формы. Автозаголовок формы документа формируется после его записи, поэтому во время работы с формой он не отражает текущего состояния. Так, если у документа изменилась дата или номер, то обновление заголовка не произойдет до момента записи.
Исправить ситуацию можно, описав функцию состояния заголовка формы.
Рисунок 4. Настройка элемента формы «ЭтаФорма». Функция состояния
Свертываемая группа. Контроллер элемента группы
У элемента свертываемой группы есть несколько ограничений: нельзя использовать свою картинку в заголовке, заголовок свернутой группы представлен в сокращенном варианте и сжат по ширине.
Рисунок 5. Свернутое состояние группы – стандартное поведение платформы 1С
Попробуем снять эти ограничения через моделирование работы свернутой группы на базе отдельных элементов: обычной группы, надписи в виде гиперссылки вместо заголовка группы и двух картинок - они будут отражать состояние свернутости группы. Для этого нам потребуется описать модель, связывающую все перечисленные выше элементы.
Рисунок 6. Модуль формы. Описание зависимостей элементов от параметров
Внимательно присмотритесь к описанию связей элементов с параметрами. Все параметры, от которых зависят элементы формы, за исключением одного, связаны с элементами ввода. Параметр «НалоговорыеРеквизиты_СвернутоеОтображение» не связан с элементом ввода и его значение определяется алгоритмически в коде реализованного контроллера.
Параметр «НалоговорыеРеквизиты_СвернутоеОтображение» является параметром собственного состояния формы. Можно сказать, что этот параметр определяет модель формы. Это слишком уж тривиальная модель и реализация отдельного слоя модели здесь не требуется – минимально необходимые действия с параметром, такие как сохранение и восстановление, реализуются на уровне платформы, а в расчетах этот параметр не может участвовать постольку поскольку всего один.
Рисунок 7. Функции состояния: группы, надписи, картинок
На выходе мы получим работающую свертываемую группу, внешне не отличимую от встроенной, однако лишенной ее ограничений. В отличии от стандартной группы в нашей реализации состояние свернутости сохраняемое.
Найденное решение достаточно общее и вполне подходит на роль шаблонного при использовании в своих формах, где требуется подобная функциональность для группы элементов.
Рисунок 8. Реализация контроллера для элемента формы декорация надписи заголовка группы
Отключаемые панели. Контроллер для кнопок
В этом примере используются элементы командного интерфейса – кнопки. Реализация кнопок подразумевает реализацию некоторого кода выполнения команды или в рассматриваемой парадигме MVC – контроллера.
Еще здесь имеются три интерфейсные группы, выполняющие роль панелей. Видимость панелей определяется состоянием кнопок: если кнопка нажата – панель видна, иначе – скрыта.
Модель формы управления панелями состоит из настройки 6-и элементов: 3-х элементов – панелей и 3-х элементов – кнопок команд управления видимостью соответствующих панелей. Эта форма также имеет собственное сохраняемое состояние, однако слой модели здесь реализовывать не требуется.
Рисунок 9. Описание настройки элементов формы
Рисунок 10. Реализация контроллера кнопок управления видимостью
Рисунок 12. Управление панелями: функции состояния
Резюме
Представленные примеры демонстрируют приемы работы с формой с использованием фреймворка «Управление состоянием». В примерах явно выделены слои реализации контроллера и представления. Слой модели здесь отсутствует, т.к. возможности стандартного поведения платформы полностью закрывают такую потребность в представленных примерах.
Однако есть ситуации, когда слой модели формы все-таки требуется реализовать. Примеры реализации модели формы заслуживают отдельной статьи, а пока ограничимся настройкой элементов формы, реализацией контроллера и функций состояния.
