Управление состоянием для шаблона MVC и работы с данными объекта

Публикация № 1202858

Разработка - Работа с интерфейсом

Интерфейс MVC Управление формой

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

Оглавление

 

Интерфейс бизнес-приложения

Связанные данные и расчет зависимостей

Связи параметров выбора

Обработка события ПриИзменении

Обобщенная обработка

Граф зависимостей

Отражение состояния в интерфейсе

Условное оформление

Управление видимостью и доступностью

Группировка данных и элементов

Функции состояния

Управление состоянием

Модель управления формы

Модель объекта и программный интерфейс

Оптимизация

Зацикливание

Ошибки

Структура модулей

Параметры состояния

Связи

Слабые связи

Параметризация

Элементы и группы

Проверка заполнения при вводе (история) и при копировании

Расчет производных параметров

Сценарии

Поставка и порядок внедрения

Вывод

Полезные ссылки


 

Я исхожу из того, что хороший интерфейс является одним из ключевых факторов успешности бизнес-приложения. Для его проектирования можно привлечь аналитиков или специалистов по взаимодействию. Однако качественная реализация такого интерфейса - второй фактор успеха, и здесь нам потребуются лучшие решения и разработчики. Поиску лучшей технологии для реализации качественных динамических интерфейсов и посвящено мое исследование, результатом которого стала разработка подсистемы «Управление состоянием».

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

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

Однако любой интерфейс работает с данными. В обычной практике данные связаны между собой. Работа с зависимыми данными позволяет минимизировать ошибки путем уменьшения объема за счет уточняющих реквизитов. Например, перед выбором договора пользователю предлагается выбрать организацию и контрагента. Это связанные данные, здесь действующий договор может быть определен однозначно для выбранной организации и контрагента, ну или список таких договоров может быть сильно ограничен и потому выбор конкретного значения договора не должен составить большого труда для пользователя.

С версии 8.2 в платформе 1С появилась возможность описывать связи параметров выбора. Этот механизм отлично подходит для декларативного задания связей реквизитов элементов формы. Однако существующие ограничения не позволяют в полной мере задействовать встроенный механизм.

Связи можно настраивать только на уровне реквизитов данных. Например, можно указать связь договора с организацией и контрагентом через связь соответствующих реквизитов справочника Договоры: Организация и Владелец. Если, например, у справочника Договоры нет соответствующих реквизитов, а связь образуется через отношение с табличной частью договора "Участники", то такую связь в платформе установить будет уже невозможно. Это ограничение можно обойти при использовании подсистемы Работа с данными выбора.

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

Единственный способ изменить поведение событийно-ориентированной системы - это найти подходящее событие и вставить в его обработчик нужный код на встроенном языке. Для расчета зависимостей подходящим событием является - "ПриИзменении". Так, для нашего примера, нам потребуется добавить код для обработчиков элементов формы Организация и Контрагент. Наш код должен будет делать следующее: проверить, соответствует ли связанный реквизит Договор с текущими значениями Организации и Контрагента. Если значение договора не соответствует условиям связей, то договор необходимо очистить и попробовать определить подходящее значение для новых условий. Если значение однозначно, то пусть система выберет его, иначе пусть возможность выбора останется за пользователем. Чтобы не дублировать код обработчиков события, вынесем его в отдельную процедуру - что-то типа "ПриИзмененииОрганизацииИлиКонтрагента", а в сами обработчики вставим её вызов.

Как видим, в предложенном решении на первый взгляд нет ничего сложного. Протестируем наше решение на предмет масштабирования и поддержки. Если нам потребуется вставить новую зависимость, например, договора от вида операции, тогда будем действовать по той же схеме: добавим обработчик и вставим вызов нашей процедуры. Еще нам нужно будет в процедуре учесть значение новой связи. Однако, что если от вида операции есть и другие зависимости? Тогда нужно будет разработать еще одну процедуру, обсчитывающую зависимые элементы и добавить ее вызов в обработчике. В общем случае получается, что для каждого элемента формы необходимо добавить обработчик события "ПриИзменении". Также требуется добавить процедуры расчета зависимых реквизитов, вызовы которых необходимо вставить в обработчики событий элементов, от реквизитов которых они зависят.

Это вполне рабочее решение, однако есть решение получше. И это не мое решение, я его где-то подсмотрел. Оно заключается в том, что вместо написания множества обработчиков событий элементов формы вся обработка изменений реквизитов реализуется в одной процедуре с рекурсивным вызовом - что-то типа "ПриИзмененииРеквизита(ИмяРеквизита, ИзмененныеРеквизиты)". Это решение лучше предыдущего, ведь здесь не требуется писать отдельные обработчики, достаточно их назначить на вызов метода формы, который вызовет нашу процедуру. Здесь второй аргумент процедуры необходим для целей оптимизации расчетов.

Чтобы понять, насколько хорошо наше второе решение, протестируем и его. Для этого усложним пример: введем новые реквизиты и зависимости. Добавим новый реквизит Статья, значение которого будет определяться договором и видом операции. Если теперь изменить значение Вида операции, то у нас появиться два пути расчета зависимостей:

  1. Вид операции->Договор->Статья
  2. Вид операции->Статья

При условии оптимизации результат расчета будет зависеть от порядка выбранных путей. Интуитивно кажется, что выбор наиболее длинного пути верный. Действительно, для нашего примера это так, однако в общем случае это не так. Правильным вариантом будет такой порядок расчета элементов зависимостей, когда зависимые элементы идут после тех, от которых они зависят. Такой порядок в теории графов называется топологическим, а сам граф должен быть при этом однонаправленным и ациклическим.

Итак, наше второе решение с выделением общей функции не оптимально: ведь оно не может использовать топологический порядок! В следующем решении рассмотрим вариант алгоритма, построенного на описании графа зависимостей. Для работы с формой нам даже не придется придумывать где хранить этот граф, ведь можно воспользоваться связями параметров выбора в элементах формы. Однако такое решение будет нас ограничивать работой с формой. Для обеспечения общности определим хранение зависимостей для формы в ее реквизите, а для объекта - в переменной (можно воспользоваться структурой Дополнительные параметры). Полное описание такого решения представлено в статье Шаблон MVC для управляемого интерфейса.

Рассмотрим данные на примере реализации документа «Заявка на операцию» из действующей рабочей конфигурации. На диаграмме размер узла пропорционален количеству связей, синий цвет соответствует данным объекта, голубой – константным параметрам.

Однако обеспечение расчета зависимостей в самом объекте недостаточно для работы пользовательского интерфейса. Дело в том, что взаимодействие с пользователем несет дополнительную семантику, которая отражена только в работе интерфейса пользователя. Например, выбор способа оплаты через кассу или банк будет определять наличие на форме элемента выбора счета контрагента. Получается, что интерфейс отражает состояние данных в соответствии с той семантикой, которая заложена в его поведении взаимодействия с пользователем. В платформе есть возможность декларативного описания настроек элементов формы от данных объекта или контекста формы – «Условное оформление». Этот механизм в полной мере хорошо работает для оформления строк таблиц, однако применительно к остальным элементам формы весьма ограниченно и поэтому практически не применяется.

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

Распространенным простым решением для настройки формы является реализация общей процедуры что-то типа «УправлениеВидимостьюДоступностью(Форма)». Если у нас есть такая процедура, то для корректного отражения состояния в представлении формы достаточно добавить вызов нашей процедуры в конце обработчика «ПриИзменении», а также «ПриСозданииНаСервере».

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

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

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

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

При изменении одного реквизита вызывать процедуру настройки всей формы не очень оптимально. Улучшим наше решение. Мы уже и так разделили нашу процедуру на отдельные участки кода, соответствующие настройке свойств отдельных элементов (группировка по элементам). Выделим код настройки элементов в отдельные функции – пусть это будут функции состояния. Тогда при изменении реквизитов, зная зависимость элементов от данных, можно вызвать настройку только тех элементов, свойства которых могли поменяться.

Добавим в нашу модель описание параметров, значения которых будут определятся как самими данными, так и на основе значений других параметров. Путь это будут «Параметры состояния», тогда зависимости элементов можно описать уже от этих параметров, т.е. функции состояния будут реализовывать настройку свойств элементов по параметрам состояния, от которых они зависят. Общий алгоритм расчета состояния формы по измененным данным будет такой: вначале определяются значения измененных параметров, которые определяются измененными данными; затем вычисляются зависимые от них параметры; определяются элементы формы, свойства которых зависят от измененных параметров; для каждого из найденных элементов вызывается своя функция состояния. Подробнее это решение представлено в статье Управление состоянием формы через конечный автомат.

На следующей диаграмме представлены связи данных с элементами формы на примере реализации документа Заявка на операцию из действующей конфигурации. Здесь также, как и на предыдущей диаграмме связей данных, размер узла пропорционален количеству связей, синим и голубым обозначены параметры, а желтым – элементы формы.

Решения для расчета зависимостей и состояния формы вполне хорошо зарекомендовали себя на практике. Использование языка зависимостей позволяет не только лучше взаимодействовать постановщикам задач и разработчикам, но и может служить некоторой основой самодокументации реализуемой системы. Теперь зависимости определяются не в самом коде, а в структуре, по которой реализуются алгоритмы расчета и это устраняет расхождения между описанием и исполнением.

Практика использования двух подсистем выявила их недостатки и преимущества. Главным недостатком использования двух подсистем оказалось дублирование описания реквизитов/параметров и связей между ними. Практически описание модели объекта повторяется в описании зависимостей и параметров состояния для формы. Две подсистемы создавались изначально независимо друг от друга и решали разные задачи отдельно: расчет данных объекта и расчет параметров состояния формы. При этом описание реквизитов обладает более богатой семантикой: это и определение ссылочных данных по связям параметров выбора, и проверка заполнения, и обработка заполнения, и обработчик события «ПриИзменении», и возможность перестроения графа зависимостей. Подсистема управления состоянием формы оперирует параметрами состояния, для которых поддерживаются только: выражения расчета значений и разные возможности хранения (реквизит данных, контекста или хранилище значений). Кроме того, обе подсистемы реализуют алгоритм обхода зависимостей: реквизитов – для подсистемы расчета зависимостей, параметров состояния – для подсистемы управления состоянием формы.

В новом решении «Управление состоянием» объединены возможности обеих подсистем. Здесь основными элементами расчетов являются параметры состояния. Их значения могут храниться как в данных объекта, так и в данных контекста формы или объекта, а также в хранилище значений параметров состояния. Для них поддерживаются: ссылочные данные и алгоритмы расчета ссылочных значений по связям параметров выбора, выражения значения, проверка заполнения, признак использования, обработчик «ПриИзменении». Кроме того, сами свойства параметров состояния и связей могут быть также параметризованы. Последнее позволяет описывать параметризованный граф зависимостей.

«Управление состоянием» - это не только оптимизация архитектуры, но и оптимизация производительности. В прежних подсистемах не была реализована оптимизация клиент-серверного взаимодействия и все расчеты всегда производились только в контексте сервера (на стороне back-end - как принято говорить в web разработке). Однако теперь клиент-серверное взаимодействие оптимизировано как по количеству вызовов, так и по объему данных. Конечно подсистема сама не всегда точно может определить нужный контекст исполнения и поэтому для тонкой настройки механизма будет требоваться конкретное указание контекста путем определения признака «НаСервере» у параметров состояния и у элементов (объект описания элемента формы).

Ориентируясь на описания свойств параметров состояния, таких, как «Проверка заполнения» и «Использование», которые также могут быть параметризованы, появилась возможность использования этой информации для подсистемы проверки заполнения и очистки – однако эта потенциальная возможность будет использована уже в другой подсистеме, описание которой не входит в рамки текущей статьи.

Описание модели формы заключается в описании её элементов и параметров состояния, от которых зависят эти элементы.

На примере элементов СуммаВзаиморасчетов и ВалютаВзаиморасчетов из прилагаемой демо-базы рассмотрим их настройку. Здесь реализуется следующее поведение. Если валюта документа совпадает с валютой расчетов, то сумма взаиморасчетов должна быть скрыта, т.к. значение этой суммы равно значению суммы документа и при таком условии элемент суммы взаиморасчетов будет дублировать ввод. Это же поведение дублируется для элемента табличной части ДвиженияОперацииСуммаВзаиморасчетов. Валюта взаиморасчетов при совпадении валют должна показывать заголовок, в противном случае её заголовок должен быть скрыт. В первом случае достаточно заголовка элемента Суммы взаиморасчетов, а во втором, когда элемент суммы скрыт, уже требуется заголовок элемента Валюты расчетов.

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

Настройка элементов СуммаВзаиморасчетов и ВалютаВзаиморасчетов:

    РаботаСФормойКлиентСервер.Элемент(ЭтотОбъект, Модель, Элементы.СуммаВзаиморасчетов, "ВалютаВзаиморасчетов,ВалютаДокумента");
    РаботаСФормойКлиентСервер.Элемент(ЭтотОбъект, Модель, Элементы.ВалютаВзаиморасчетов, "ВалютаВзаиморасчетов,ВалютаДокумента,ДоговорКонтрагента");

Функции состояния элементов, обеспечивающие заданное поведение:

Функция СвойстваСуммаВзаиморасчетов(Свойства, Параметры) Экспорт
    Свойства.Вставить("Видимость", НЕ Параметры.ВалютаВзаиморасчетов = Параметры.ВалютаДокумента);
    Возврат Истина;
КонецФункции

Функция СвойстваВалютаВзаиморасчетов(Свойства, Параметры) Экспорт
    Если Параметры.ВалютаВзаиморасчетов = Параметры.ВалютаДокумента Тогда
        Свойства.Вставить("ПоложениеЗаголовка", ПоложениеЗаголовкаЭлементаФормы.Авто);
    Иначе
        Свойства.Вставить("ПоложениеЗаголовка", ПоложениеЗаголовкаЭлементаФормы.Нет);
    КонецЕсли;
    Свойства.Вставить("ТолькоПросмотр", ЗначениеЗаполнено(Параметры.ДоговорКонтрагента));
    Возврат Истина;
КонецФункции

Полное описание модели формы в обработчике ПриСозданииНаСервере:

 

На следующем слайде представлена модель данных, где синим обозначены реквизиты объекта, а желтым – элементы формы.

На следующем слайде продемонстрирован граф последовательности изменений при выборе значения контрагента (красным – измененные данные, оранжевым – зависимые элементы):

Модель объекта описывает только данные предметной области. В качестве абстракции данных в модели принято понятие Параметра состояния. Параметр состояния может определяться как ссылочное значение по связям параметров выбора, по выражению или функции значения, а также в обработчике ПриИзменении другого параметра. Значение параметра может храниться в данных объекта, контекста или в хранилище значений параметров состояния.

Описание модели содержится в структуре Модель, которую должна возвращать одноименная функция менеджера объекта. Пример описания модели объекта представлен ниже.

Важной частью реализации является возможность использовать модель в алгоритмах без участия формы объекта. На представленном примере (следующий слайд) в объекте устанавливается новая дата и валюта. Измененные реквизиты служат основой расчета зависимостей модели объекта. После возвращения данных объекта в контекст формы достаточно выполнить расчет производных параметров состояния (параметров, которые не сохраняются в объекте и значения которых определяются данными объекта или контекста).

В подсистеме поддерживается оптимизация клиент-серверного взаимодействия по объему данных и по количеству контекстных вызовов. Также оптимизирован сам расчет – расчет начинается от изменённых параметров и завершается при достижении последнего в графе зависимостей или, когда значение параметра пустое при условии обязательного заполнения.

Чтобы система работала необходимо соблюдать одно условие – граф зависимостей должен быть однонаправленным и ациклическим. Именно такой граф может обеспечить топологический порядок параметров состояния.

Диагностика ошибки в системе очень важна. Тут дело не только в том, что ошибка в алгоритме может сделать дальнейшую работу пользователя невозможной или приведет к потери введённых данных, а в том, что система вполне может продолжить работу, однако консистентность будет нарушена. Последнее обстоятельство может перечеркнуть все достоинства системы, поэтому важно отслеживать ошибки расчета зависимостей и максимально оперативно их устранять.

Для расследования причины ошибки необходимо знать не только место её возникновения, но и контекст. В декларативных системах знание контекста определяющее, т.к. поведение системы полностью определяется им. Стандартная обработка ошибки нам мало сможет помочь, поэтому в системе предусмотрена расширенная диагностика ошибок.

В процессе расчета зависимостей есть несколько потенциальных точек отказа:

  • функция значения (параметр состояния);
  • обработчик события «ПриИзменении» (параметр состояния);
  • функция состояния (элемент формы)

В подсистеме предусмотрено дополнение описания ошибки значениями контекста возникновения. Такое дополнение позволяет точно определить источник ошибки: конкретный параметр состояния или элемент формы, а также обработчик события.

Подсистема предполагает реализацию функции Модель в модуле менеджера объекта. Кроме описания самой настройки модели необходимо описание функций состояния, значения и обработки событий ПриИзменении. Эти функции должны располагаться в общем модуле доступном для контекста клиента и сервера. При этом функции, которые требуют для своего исполнения контекста только сервера, должны быть заключены в блоке препроцессора #Если Сервер Тогда … #КонецЕсли

Структура модуля формы

Структура модели

См. описание РаботаСМодельюКлиентСервер.Модель.

Пример создания модели в демо базе модуль менеджера Документ.ЗаявкаНаОперацию.Модель.

См. описание РаботаСМодельюКлиентСервер.Параметр

В большинстве случаев создавать отдельно параметр состояния не требуется. Параметры состояния создаются в модели неявным образом при добавлении новых связей. Однако если настройка параметра состояния по умолчанию вас не устраивает, то ее можно изменить непосредственно, обратившись к параметру через структуру модели Модель[ИмяПараметра] или безопасным образом через функцию РаботаСМодельюКлиентСервер.Параметр[ИмяПараметра].

См. описание РаботаСМодельюКлиентСервер.Связь

В описании модели связи решают все! Формально модель - это параметры состояния и их связи (для формы добавлены элементы), однако описывать параметры состояния отдельно в большинстве случаев не нужно: достаточно добавить описания связей. Система сама, на основе анализа контекста, определит описания параметров. Такой подход имеет одно ограничение: имена реквизитов объекта и формы не должны пересекаться (не относится к реквизитам табличных частей).

Ограничение на однонаправленность и ацикличность связей может быть для некоторых требований слишком жестким. Например, счет контрагента определяется по связям как Валюта документа->Счет контрагента, однако пользователю удобно выбрать счет в нужной валюте. В таком случае указанная связь оказывается слабой.

Концепция слабой связи работает для интерактивного выбора. При интерактивном выборе значения слабые связи не используются для установления условий отбора. Такое поведение интерфейса позволяет сделать выбор значения, которое будет противоречить условию существующей связи. Чтобы соблюдалась консистентность данных в обработчике события ПриИзменении необходимо определить алгоритм установки правильного значения связи. Пример такого обработчика ПриИзменении можно посмотреть в демо: МодельЗаявкаНаОперацию.ПриИзмененииСчетКонтрагента.

При определении слабой связи может возникнуть вопрос: в какую сторону направить связь, а в какую использовать обработчик ПриИзменении? Ответ на этот вопрос определяется порядком расчета модели. Этот порядок определяет направление связи. Если требуется для интерактивного выбора отключить ограничение связи, то используется слабая связь, а в обработчике ПриИзменении выбранного параметра определяется алгоритм расчета значения связанного ведущего параметра.

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

В следующем обработчике анализируется направление слабой связи, которое зависит от типа операции. Для внешней операции это Валюта документа->Счет контрагента, а для внутренней (конвертация валюты) – Валюта взаиморасчетов->Счет контрагента. И конечно же, если среди рассчитанных реквизитов уже есть валюта, то никакой обратной связи не требуется!

Процедура ПриИзмененииСчетКонтрагента(Контекст, Объект, ДанныеСтроки, Реквизит, ИзмененныеРеквизиты, РассчитанныеРеквизиты) Экспорт
  Если Объект.ТипОперацииБюджетирование = Перечисления.ТипыОперацийБюжетирование.КонвертацияВалюты Тогда
    ИмяРеквизитаВалюты = "ВалютаВзаиморасчетов";
  Иначе
    ИмяРеквизитаВалюты = "ВалютаДокумента";
  КонецЕсли;
  Если РассчитанныеРеквизиты[ИмяРеквизитаВалюты] = Истина ИЛИ НЕ ЗначениеЗаполнено(Объект.СчетКонтрагента) Тогда
    Возврат;
  КонецЕсли;
  РаботаСМодельюКлиентСервер.УстановитьЗначение(Контекст, ИмяРеквизитаВалюты, , ОбщегоНазначения.ЗначениеРеквизитаОбъекта(Объект.СчетКонтрагента , "Валюта"), ИзмененныеРеквизиты);
КонецПроцедуры

Иногда удобно одни и те же параметры использовать в разных связях. Например, связь Контрагент->Счет контрагента определена для внешней операции, однако для внутренней операции указанная связь как и сам реквизит Контрагент становятся недействительными. Для разного типа операции существуют разные связи: Контрагент->Счет контрагента – для внешней, Организация->Счет контрагента – для внутренней.

В предыдущей версии подсистемы существовала возможность перестроения графа зависимостей, однако в новой подсистеме это достигается путем параметризации. Так для первой связи можно указать, что свойство «Использование» определяется параметром ЭтоВнешняяОперация, а для второй – ЭтоВнутренняяОперация. Аналогично свойство «Использование» определяется и для реквизита Контрагент.

Механизм параметризации позволяет описывать динамическую модель объекта, где свойства связей и параметров сами описываются через другие параметры.

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

В рамках подсистемы управления состоянием формы реализовано описание элементов и их групп. Здесь под группами понимается не родительский элемент с его подчиненными элементами, а список элементов, поведение которых настраивается общим способом через настройку группы.

Деятельность отдельного пользователя может быть очень специализированной. В этом суть разделения труда, когда одни работают с поставщиками, другие с покупателями, третьи рассчитывают зарплату. Такая специализация приводит к использованию ограниченного набора данных и повторяемости выбора для одних и тех же условий, с которыми имеет дело пользователь. Накопление статистики и предугадывание того, какое значение будет выбрано пользователем в следующем реквизите – позволяет сделать систему адаптивной под рабочие предпочтения пользователя. Такая адаптивность системы не только увеличивает производительность работы пользователя, но и уменьшает вероятность ошибки ввода данных в систему.

В основе адаптивности ввода лежит платформенный механизм истории выбора значений при вводе. У него есть свои ограничения. Так, если выбор значения переопределен в модуле менеджера (ОбработкаПолученияДанныхВыбора), то платформенный механизм не будет учитывать новые критерии выбора. Второе ограничение связано с тем, что платформенный механизм ориентируется на неизменность данных: т.е., например, если для данной организации и контрагента выбран договор один раз, то и в следующий раз для тех же организации и контрагента можно выбрать тот же договор, однако если в самих данных для договора поменять значение контрагента, то платформенный механизм никак это не учтет и позволит сделать уже неверный выбор. Можно рассмотреть пример и попроще. Пусть в параметрах выбора определено значение пометки удаления Ложь (отбор только не помеченных на удаление элементов), тогда если элемент пометить, то платформа не только позволит сделать выбор из истории, но и никак не предупредит, что выбранный элемент помечен на удаление!

К сожалению список истории ввода никак нельзя переопределить из встроенного языка. Сама 1С для таких случаев, где действуют ограничения, рекомендует отключать историю выбора. Однако этот механизм повышает удобство работы пользователя и отказываться от него нерационально. Решением здесь будет продолжать использовать механизм там, где он востребован, а для разрешения ограничений использовать дополнительную проверку ввода. Тогда сама платформа будет продолжать предлагать пользователю значения для быстрого ввода исходя из накопленной статистики, однако на встроенном языке будет выполняться дополнительная проверка, которая не позволит ввести значение, которое перестало быть валидным.

Механизм проверки введенного значения активизируется для всех полей ввода с установленным свойством элемента формы ИсторияВыбораПриВводе равным Авто. Такая проверка может привести к нежелательному поведению системы. Например, мы хотим ввести в поле Сумма расчетов свое значение, тогда при проверке система рассчитает значение через кросс-курс от суммы документа и заменит им наше. Чтобы такого не происходило, необходимо для полей с числовыми данными отключать историю выбора через установку значения НеИспользовать.

Копирование информационного объекта - есть ничто иное как ввод информации для нового объекта по данным исходного. При этом возможна ситуация, когда данные валидные в прошлом перестали соответствовать текущим параметрам выбора. В таком случае необходимо также, как и при вводе значения из истории, выполнить проверку данных на соответствие текущим ограничениям.

Следующий код демонстрирует проверку данных нового объекта через метод ОбновитьДанные.

Процедура ПриКопировании(ОбъектКопирования)
  Дата = ТекущаяДата();// дата требуется для расчета кросс-курса
  РаботаСМоделью.Инициализировать(ЭтотОбъект);//  конструируется модель объекта
  РаботаСМоделью.РассчитатьПроизводныеПараметры(ЭтотОбъект);//  расчет не сохраняемых параметров
  РаботаСМоделью.ОбновитьДанные(ЭтотОбъект);//  проверка сохраняемых данных на соответствие модели
КонецПроцедуры

Изменение данных объекта приводит к пересчету связанных зависимостью параметров. Однако бывают ситуации, когда параметры не входят в цепочку зависимостей или, когда требуется перенести данные объекта в контекст формы. В первом случае источником изменения данных может быть внешнее событие, например, это может быть событие записи объекта. В обоих случаях для восстановления значений расчетных параметров, которые не сохраняются в объекте, требуется выполнить их расчет.

Например, при проведении документа меняется его состояние, значения которого хранится в регистре. После проведения документа требуется заново определить значение параметра «Состояние».

Второй пример с переносом данных объекта в контекст формы можно посмотреть в демо-базе в обработчике команды «Изменить данные объекта». Здесь происходит вначале конвертация данных формы в объект, затем производятся изменения данных объекта и объект возвращается в контекст формы (см. Модель объекта и программный интерфейс).

Расчет Зависимости от договора

Сценарий к разделу Модель управления формы.

Используемые зависимости модели объекта:

...
  //  Связи параметров выбора для договора
  РаботаСМодельюКлиентСервер.Связь(Контекст, Модель, "ДоговорКонтрагента", "Организация", "Отбор.Организация");
  РаботаСМодельюКлиентСервер.Связь(Контекст, Модель, "ДоговорКонтрагента", "Контрагент", "Отбор.Контрагент");
  //  Связь валюты расчетов от договора по параметру ДоговорКонтрагента. На связь наложено условие использования: для внешней операции (Оплата поставщику)
  РаботаСМодельюКлиентСервер.Связь(Контекст, Модель, "ВалютаВзаиморасчетов", "ДоговорКонтрагента",,, Новый Структура("Использование", "ЭтоВнешняяОперация"));
  //  Следующие связи определяют расчет суммы взаиморасчетов от суммы документа, кросс-курса
  РаботаСМодельюКлиентСервер.Связь(Контекст, Модель, "СуммаВзаиморасчетов", "СуммаДокумента");
  РаботаСМодельюКлиентСервер.Связь(Контекст, Модель, "СуммаВзаиморасчетов", "КроссКурс");
  //  Аналогичные связи для табличного реквизита сумма взаиморасчетов
  РаботаСМодельюКлиентСервер.Связь(Контекст, Модель, "ДвиженияОперации.СуммаВзаиморасчетов", "ДвиженияОперации.Сумма");
  РаботаСМодельюКлиентСервер.Связь(Контекст, Модель, "ДвиженияОперации.СуммаВзаиморасчетов", "КроссКурс");
  //  Связи, определяющие расчет кросс-курса от даты и валюты документа, валюты расчетов
  РаботаСМодельюКлиентСервер.Связь(Контекст, Модель, "КроссКурс", "Дата");
  РаботаСМодельюКлиентСервер.Связь(Контекст, Модель, "КроссКурс", "ВалютаДокумента");
  РаботаСМодельюКлиентСервер.Связь(Контекст, Модель, "КроссКурс", "ВалютаВзаиморасчетов");
...

 

Название:

Заполнение договора контрагента

Описание:

После выбора договора система заполняет валюту и сумму расчетов. Элемент формы Валюта расчетов становится недоступным для редактирования.

Предусловия:

В документе заполнены: операция Оплата поставщику, Организация, Контрагент, значение Валюты документа равна Валюте расчетов рубли. Договор контрагента не заполнен.

Основной поток:

  1. Пользователь вводит значение договора в USD
  2. Модель по данным зависимостей производит заполнение валюты расчетов
  3. Модель рассчитывает кросс-курс валюта документа -> валюта расчетов
  4. Модель заполняет сумму расчетов по рассчитанному кросс-курсу и сумме документа
  5. Модель заполняет сумму расчетов для строк табличной части аналогично 4
  6. Модель определяет список измененных элементов формы по зависимостям от измененных реквизитов
  7. Форма отображает элемент суммы расчетов, скрывает заголовок элемента валюта расчетов, отображает колонку Сумма расчетов и формирует её заголовок по шаблону: Сумма, [валюта расчетов]

 

Требования: Платформа 8.3.14 и выше для работы в тонком и веб клиенте.

Подсистема

Метаданные

Назначение

 

Общий модуль:

 

БСП.БазоваяПодсистема

 

 

УправлениеСостоянием

Общий

 

 

ОбщийКлиентСервер

 

 

РаботаСДаннымиВыбора

Обеспечивает нестандартную обработку выбора

 

РаботаСоСхемойЗапроса

Используется для описания запроса в подсистеме работы с данными выбора

 

РаботаСМоделью

 

 

РаботаСМодельюКлиентСервер

 

 

РаботаСФормой

 

 

РаботаСФормойКлиентСервер

 

Демо

Документ.ЗаявкаНаОперацию

 

 

МодельЗаявкаНаОперацию

Описание модели документа ЗаявкаНаОперацию

 

Справочники: Контрагенты, ДоговорыКонтрагентов, Организации

 

Порядок внедрения:

  1. Выгрузить конфигурацию из демо-базы
  2. Объединить с целевой конфигурацией с отбором по подсистеме УправлениеСостоянием

Подсистема "Управление состоянием" расширяет возможности определять поведение объекта и его интерфейса на основе декларативного описания параметров состояния и связей. Единая подсистема решает задачу шаблона MVC, а также позволяет описывать сложное поведение интерфейса, задавать правила проверки заполнения и очистки данных.

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

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

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

 

Проект в формате EDT опубликован на gihub.

Лучшее объяснение идеи MVC:

Другие материалы по теме в статьях Infostart.ru:

Смотрите также разбор примера.

 

Скачать файлы

Наименование Файл Версия Размер
sm1_0_0_9
.dt 4,31Mb
05.04.20
2
.dt 1.0.0.8 4,31Mb 2 Скачать

Специальные предложения

Комментарии
Избранное Подписка Сортировка: Древо развёрнутое
Свернуть все
1. pm74 169 18.03.20 18:00 Сейчас в теме
интересная статья
у любой модели(системы) управления сложной логикой поведения ( в т.ч. КА ) , помимо очевидных плюсов, есть и один минус - ее очень трудно понимать без поддерживающей (графической или табличной) нотации
как в вашей подсистеме с этим обстоят дела ?
2. kalyaka 580 18.03.20 18:55 Сейчас в теме
(1) спасибо за Ваш интерес
Я предполагаю, что к этой системе должен прилагаться конструктор. В таком конструкторе можно было бы визуально настраивать связи и генерировать код модулей формы и модели. Другое назначение конструктора: конвертация существующих форм в модель УС.

А визуализировать графически можно любыми инструментами, данные из системы можно получить из одной структуры: Модель. Графы на скриншотах в статье я делал так: в отладчике выгружал структуру во внутренний формат 1С, далее переносил в ИР (исполнитель кода) и там по структуре генерировал текстовый файл в формате dot для отображения программой graphiz.
3. pm74 169 18.03.20 19:12 Сейчас в теме
(2) да я и имел в виду конструктор
(2)
настраивать связи и генерировать код модулей формы и модели

или же просто создавать формальное описание модели которое может быть связано с представлением средствами вашей подсистемы
правда не до конца представляю как такая модель должна выглядеть
6. kalyaka 580 18.03.20 22:48 Сейчас в теме
(3) может сделать возможность загружать описание модели из форматов json или yaml?
Второй формат может быть удобным для написания человеком. Тогда можно было бы из конструктора сохранять модель в json для вставки в код, а загружать из подготовленного человеком или другой системой файл yaml.

В коде на выбор можно было бы описывать модель через программный интерфейс - удобно в отладке и в алгоритмах или просто вставлять json для жесткой модели.
4. Vladimir Litvinenko 2327 18.03.20 19:48 Сейчас в теме
Чтобы система работала необходимо соблюдать одно условие – граф зависимостей должен быть однонаправленным и ациклическим.

Обеспечение этого требования ложится на плечи разработчика, или в подсистему встроена диагностика? (выбрасываются исключения например)


Эх, пример бы ещё кода более объемный с комментариями к коду. Попытался построить в голове полноценную картинку - чуть голову не сломал )) Надо отложить повторное прочтение до выходных ))

Вот например взять функцию Модель() из модуля менеджера ЗаявкаНаОперацию и подробно её разобрать или на Гитхабе код сдобрить комментариями. Или описать стек вызовов - как код доходит до ВыполнитьВыражениеЗначения например.


Стиль изложения больше литературный, а графы из graphiz честно говоря не сильно помогают понять алгоритмы )) Пока шло описание решаемой проблемы и первых идей для решения всё было понятно. И то, что с этими проблемами постоянно сталкиваешься на практике очень мотивировало к дальнейшему прочтению. Но когда дело дошло до середины статьи мозг попросил пощады ))

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

Ещё интересно как это решение заходит при командной разработке. Ведь по идее при совместном применении такого решения (и ранее опубликованных решений) нужна какая-то техническая документация. Что-то типа "делай раз - делай два - делай три - вот результат".
CyberCerber; +1 Ответить
7. kalyaka 580 18.03.20 23:29 Сейчас в теме
(4)
Обеспечение этого требования ложится на плечи разработчика, или в подсистему встроена диагностика?
Я думал над этим, у меня даже такой раздел есть - "Ошибки". Подробная регистрация ошибок в такой системе очень важна, ведь код - декларативный и понять, где ошибка, можно только по описанию состояния, при котором произошла ошибка. Эту тему я буду развивать в подсистеме в сторону повышения информативности и логирования в журнале. И дело даже не просто в ошибке алгоритма, а в том, что ошибка расчета зависимостей может привести к неконсистентному состоянию объекта и это уже будет ошибка в данных.
В статье перечислены критичные точки отказа. Проверка же графа зависимостей - это такая точка отказа, которую ни с чем не спутаешь - программа вылетит с переполнением стека при попытке выполнить топологическую сортировку параметров состояния. Я сперва хотел поставить здесь проверку на зацикливание, однако алгоритм сортировки мне так понравился своей простотой и оптимальностью, что испортить его дополнительным кодом проверки у меня не поднялась рука :) Тем более, что я еще хочу сделать конструктор модели, и вот там эта проверка должна быть обязательно.
Эх, пример бы ещё кода более объемный с комментариями к коду
Проект выложен на gihub, до конца года хочу его довести до уровня полноценной рабочей эксплуатации на проде. Перед выводом на прод я планирую в демо конфигурации добавлять все больше рабочих сценариев и, конечно, же писать комментарии. Еще буду писать сценарии. Еще хочу написать конструктор. Демо, сценарии тестирования, конструктор - все это должно снизить порог понимания подсистемы.
Видимо схемы самому рисовать придётся, чтобы разобраться
С удовольствием помогу разобраться, ведь в эту систему я вложил душу :)
как это решение заходит при командной разработке
Это интересная мысль. Например есть некоторый функционал, который реализуется обработкой, представляющей АРМ. Этот АРМ реализует очень сложное поведение. Его форма разбита на отдельные фреймы, каждый из которых реализует независимую функциональность и имеет свою модель. Или пример попроще, есть сложный документ и его доработка ведется разными разработчиками. При традиционном подходе им придется решать конфликты кода, а при декларативном - делить элементы и параметры состояния.
Что-то типа "делай раз - делай два - делай три - вот результат
Это подход для быстрой разработки и моя система способствует такому подходу и дает возможность получить выгоды. То что такая инструкция необходима - согласен.
Vladimir Litvinenko; +1 Ответить
8. Vladimir Litvinenko 2327 18.03.20 23:56 Сейчас в теме
(7) Спасибо за столь серёзный подход! Если сам не смогу разобраться - задам вопросы. Но думаю что всё же посидеть в отладчике будет более правильным решением ))

Вот с применением на продуктиве большие вопросы. Без наличия документации применение на продуктиве запутанной (или кажущейся запутанной) библиотеки может быть неправильным по отношению к коллегам. Ни один программист не работает на проекте вечно и потом его сопровождать другим приходится. Поэтому нужна либо документация (как например у запутанной но задокументированной БСП), либо придерживаться KISS (хотя каюсь, у самого не всегда получается).
11. kalyaka 580 23.03.20 09:13 Сейчас в теме
(8) Обновил статью, добавил примеры кода и ссылки по тексту. Дополнил разделы: Ошибки, проверка заполнения при вводе и при копировании, сценарии.
Vladimir Litvinenko; +1 Ответить
33. kalyaka 580 08.04.20 22:38 Сейчас в теме
5. pm74 169 18.03.20 20:10 Сейчас в теме
было дело пытался сделать подобие конструктора для КА , идея была представить его в виде дерева и затем разложить в "плоскую" структуру , чтобы потом в коде можно было просто переходить от одного индекса к другому по условиям

а вообще презабавная штука , можно было бы озадачится на тему ндка, формальной верификации , моделей крипке и проч. , но тема слишком затратная по времени и надо зарабатывать на "хлеб насущный"
Прикрепленные файлы:
12. kalyaka 580 23.03.20 09:34 Сейчас в теме
(5)
но тема слишком затратная по времени
Вот так получается, что мало придумать или даже реализовать что-то. Еще не мало усилий нужно приложить, чтобы донести идею до других :)
13. pm74 169 23.03.20 10:00 Сейчас в теме
(12) нужно дать простой инструмент желательно интерактивный (типа скд) , хотя даже это не факт что взлетит
как идея насчет таблицы правил , которую можно добавлять к форме в момент создания ?
14. kalyaka 580 23.03.20 10:33 Сейчас в теме
(13) эту реализацию можно представить по типу платформенного механизма Условное оформление, обсуждали здесь
15. pm74 169 23.03.20 11:08 Сейчас в теме
(14) сейчас краем глаза посмотрел

Значительно проще сериализовать неподдерживаемое условное оформление формы (включая условия СКД) в реквизит формы, дав программисту в руки безконтекстную клиент/серверную функцию обновления по зависимому реквизиту или обновляемому контролу



Так вот, если эти две модели соединить (MVC и состояние формы), то в модуле формы ничего программировать вообще не нужно будет - весь код будет располагаться для модели в модуле Менеджера (например), а для состояния в функциях состояния.


я имею в виду что от кодирования модели можно избавиться в принципе ,
заменив это ее формальным представлением в виде справочника, регистра или чего то еще
16. kalyaka 580 23.03.20 11:16 Сейчас в теме
(15) Будет табличное программирование :)
17. pm74 169 23.03.20 11:25 Сейчас в теме
(16) так оно уже и есть , та же скд например
18. kalyaka 580 23.03.20 11:38 Сейчас в теме
(17) Тут несколько вопросов: что требует меньших трудозатрат со стороны программиста, насколько будет производительно решение, насколько читабельно.

Возможно с таблицами может получиться. Пример такой реализации в стандартной обработке настройки технологического журнала. Там используется табличный подход описания состояния журналирования.

А вот как быть с производительностью, когда на каждое состояние будет приходится несколько запросов СКД? И как реализовать эту работу в контексте клиента?
19. pm74 169 23.03.20 11:45 Сейчас в теме
(18) пример скд был надуманый , чтобы показать , что быстрая визуальная настройка снижает порог вохождения и делает подсистему более понятной для конечного пользователя

вопрос реализации пока остается открытым
20. pm74 169 23.03.20 11:51 Сейчас в теме
(18) кстати в обработке которую приложил как раз есть пример (ущербный конечно, но все таки) обработки по состояниям в контексте клиента
9. pm74 169 19.03.20 09:53 Сейчас в теме
"в плане дежурного бреда"))
написал утром обработку на тему декларативного описания модели
Прикрепленные файлы:
ВнешняяОбработка1.epf
10. CyberCerber 554 19.03.20 17:30 Сейчас в теме
Мне самому интересны такие темы, но в процессе прочтения статьи понял, что мне просто "тяму" не хватает все это понять.
Выше уже писали, было бы классно как-то больше разжевать эту тему, с конкретными примерами, потому что сама-то тема стоящая, но никуда пойти сейчас не может.
32. kalyaka 580 08.04.20 22:32 Сейчас в теме
(10)
с конкретными примерами
Опубликовал подробный пример программирования формы с использованием подсистемы.
21. Makushimo 155 25.03.20 09:46 Сейчас в теме
Не смог прочитать статью. Почему все черное?
Это не круто. Это просто не читается. Из восприятия выпадает огромный кусок материала.
Жесть.
Ох уж эти любители темных тем ночных....
22. for_sale 854 29.03.20 07:14 Сейчас в теме
Пишите вы как-то заковыристо, конечно)

Это вполне рабочее решение, однако есть решение получше

Довольно сомнительно. Если я правильно понял, то первое решение - добавить обработчик события элементу и прописать оттуда вызов какого-то обобщённого обработчика. Второе - добавить обработчик элементу, вызвать оттуда один общий обработчик, внутри этого обработчика прописать через Если обработку. Я бы выбрал первое решение. Во-первых, второе решение не даёт ничего в плане изменяемости. Т.е. всё равно нужно добавлять обработчик новому (или старому) элементу, и всё равно нужно дорабатывать имеющийся код. Но при этом в первом решении всё добавленное можно действительно вынести и визуально в отдельную часть модуля, и семантически - вызывать добавленные модули. А во втором решении нужно коверкать существующий код обработчика. Во-вторых, в таком универсальном обработчике читабельность кода обратнопропорциональна количеству вызовов. Если форма большая и хотя бы двадцать элементов вызывают этот код, то там будет уже просто каша. Ещё интереснее будет, если есть пересекающиеся двойственные или тройственные связи. Тогда в этом общем обработчике начнутся такие пляски:
Если Имя = "Организация" Тогда
Если ЗначениеЗаполнено(Контрагент) Тогда
...
ИначеЕсли Имя = "договор" Тогда
Если НЕ ЗначениеЗаполнено(Контрагент) Тогда
Если ЗначениеЗаполнено(Организация) Тогда
Если ВидОперации = ... Тогда
...
ИначеЕсли Контрагент = Пустой И Имя = "ВидОперации" Тогда
... 
Показать


В общем, я думаю, что обработчики нужно держать минимально возможными, а не шпиговать всё в одну бочку, которую потом нужно будет постоянно дошпиговывать.

Ну и производительность, конечно, тоже страдает, пусть и не сильно. Если, чтобы добраться до нужного реквизита в этой веренице Если, придётся проверить 5-10-20-100 условий, особенно, если эти условия ещё и что-то высчитывают.
24. kalyaka 580 29.03.20 14:06 Сейчас в теме
(22)
второе решение не даёт ничего в плане изменяемости
С одной стороны в 1-ом способе, вроде как, соблюдается принцип "разделяй и властвуй", с другой - увеличивается вероятность появления спагетти кода. Я в свое время на обычных формах был сторонник именно 1-го способа (см. Программирование интерфейсов в 1С или паттерн MVC для 1С), но с оговоркой о необходимости держать в уме, а лучше в комментариях граф зависимостей и придерживаться его при каскадных вызовах обработчиков.

С другой стороны, во 2-м способе не нужно прописывать каждый обработчик отдельно, достаточно установить общее действие для всех элементов формы в обработчике ПриСозданииНаСервере. Также не нужно подбирать нужный обработчик при изменениях зависимостей, т.к. он один - обобщенный.
в таком универсальном обработчике читабельность кода обратнопропорциональна количеству вызовов
Соглашусь! Вы прекрасно это проиллюстрировали в своем примере.
Ещё интереснее будет, если есть пересекающиеся двойственные или тройственные связи
Про это я упомянул в контексте решения задачи отображения интерфейса Группировка данных и элементов и то, что Вы упомянули это здесь, показывает, что задачи расчета модели предметной области и интерфейса очень похожи - и там, и там есть связи и расчет зависимостей.
Ну и производительность, конечно, тоже страдает, пусть и не сильно
Страдает, и главное не понятно как можно это оптимизировать. А если еще и решать задачу оптимизации клиент-серверного взаимодействия, то вообще становится все очень сложно.
придётся проверить 5-10-20-100 условий
Согласен! Сложность ведь ни куда не девается, она просто собралась в одном месте :)

На самом деле рассмотрение этих двух способов в статье - это прием, позволяющий поэтапно искать решения, сталкиваться с их ограничениями и, наконец, перейти к пониманию необходимости построения такой системы, у которой бы было внешнее описание по типу метаданных. Такой системой является предложенное решение Управление состоянием - здесь работа алгоритмов построена на данных описания Модели.
26. for_sale 854 29.03.20 15:49 Сейчас в теме
(24) Давайте проведём подробное сравнение обоих способов по параметрам:

1. Читабельность.
Тут, думаю, и обсуждать нечего. Первый способ вне конкуренции, т.к. этот самый граф в нём как раз отлично просматривается. А говоря человеческим языком - оттолкнувшись от любого элемента формы я могу с минимальными препятствиями пройти до конца обработки. Во втором же способе мне нужно будет продираться через ваш огромный обработчик.

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

Извините, но, мягко говоря - нет, грубо говоря - чушь. По трудозатратам написать "ПриИзмененииДоговора()" и "ПриИзмененииРеквизита("Договор")" примерно то же самое. А вот найти нужное место, чтобы впихнуть обработку конкретного реквизита, в вашем огромном обработчике, нужно потратить небольшое, но время, в первом же способе нужно просто с нуля написать обработчик.

3. Простота доработки.
И при изменениях зависимости тоже надо всё менять во втором способе, т.к. у вас код прописан в огромном обработчике, вам всё равно его нужно переписать, если логика поменялась. Ещё интереснее становится, когда ваш обработчик становится частью поставки на замке. Добавить новый элемент без изменения поставки вообще невозможно становится.

(24)
увеличивается вероятность появления спагетти кода

Почему? Не пишите спагетти - не будет спагетти) Более того, вы изначально осознанно создаёте эти самые спагетти во втором способе. Т.е. сознательно создаёте чан, куда заливаете всё, что можно.

Вы пишете об MVC, но вы его как раз разрушаете этим самым обработчиком. У теоретиков программирования это, по-моему, называется "Толстый тупой уродливый контроллер". Т.е. есть вью - это форма с элементами, есть модель - это БД и работа с нужными данными, и есть контроллер - это вот этот самый ваш огромный обработчик. Вместо того, чтобы он просто рассказал модели о том, что хочет вью, вы туда намешали и функциональностью вью, и функциональность модели. Например, если я поменяю имя реквизита с Договор на ДоговорКонтрагента, то мне нужно будет менять его в том числе и в вашем обработчике. Для первого же способа имя реквизита не имеет значения - мы из вью оповещаем контроллер (один из, нужный в данной ситуации, а не ТНЕ) о сути операции, и контроллер, не зная даже, что там у вью за элементы, как и модель, просто пробрасывает команду на модель. Сохраняется дух этой парадигмы - контроллер служит тоненькой прослоечкой, абстрагирующей команду представления для модели.

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

В общем, не убедили)
27. kalyaka 580 29.03.20 22:17 Сейчас в теме
(26)
сравнение обоих способов по параметрам
Оба способа меня не устраивают и здесь я предлагаю другое решение - решение основанное на декларативном описании модели объекта и формы.
Вы пишете об MVC, но вы его как раз разрушаете этим самым обработчиком
MVC у меня упоминается только в названии статьи и в источниках про почитать об MVC. В самой статье ничего конкретно про MVC нет. Здесь MVC выступает в роли идеи выделения программных слоев. В примере раздела Модель объекта и программный интерфейс приводится фрагмент кода работы с объектом без формы, где поведение модели обеспечивается точно такое же как при работе из формы.
28. for_sale 854 30.03.20 06:21 Сейчас в теме
(27) MVC - это парадигма, которая помогает в программировании. Если во втором способе нет MVC, то это уже повод задуматься над его полезностью.


(27)
решение основанное на декларативном описании модели объекта и формы.

Да, это то самое как раз, где ничего не понятно, но очень интересно) Как-нибудь ещё попробую пройтись по этой лабораторной, может, если совсем медленно читать...
23. for_sale 854 29.03.20 07:24 Сейчас в теме
В общем, ничего не понял, но очень интересно) Интригующая суть похоронена под казённо-формалистическим языком, как будто автор писал не для аудитории, а для лабораторной работы, чтобы сдать и забыть.
25. kalyaka 580 29.03.20 14:32 Сейчас в теме
(23) Спасибо за Ваш интерес!
Интригующая суть похоронена под казённо-формалистическим языком
А вот в другом комментарии (4) был такой отзыв:
Стиль изложения больше литературный
- это, я так понял, в первой части изложения.

В общем я осознаю, что тема интересная, а решение не достаточно раскрыто. В ближайшее время я готовлю к публикации продолжение: в нем я рассмотрю на простом примере пошаговую инструкцию (4)
Что-то типа "делай раз - делай два - делай три - вот результат"
на примере создания интерактивной формы.

Так что следите за публикациями. Я планирую продолжить раскрывать "секреты" использования подсистемы и дальше. У меня есть много кейсов, которые смогут раскрыть разные возможности подсистемы и Ваши комментарии будут служить мне ориентиром в приоритетах их рассмотрения.
29. for_sale 854 30.03.20 06:52 Сейчас в теме
(25)
А вот в другом комментарии (4) был такой отзыв:
Стиль изложения больше литературный

Боюсь даже представить, на какой литературе рос автор комментария)) Если бы литература писалась таким языком, то я бы тогда лучше посвятил детство и юность гоп-стопам и наркотикам))
30. dijee 17 30.03.20 11:28 Сейчас в теме
(29) Видимо у вас действительно так плохо с продажами =) Всем прилетает "чёпик".
31. for_sale 854 30.03.20 11:42 Сейчас в теме
(30) Ой, а ты так разобиделся, что пошёл изучать мои комментарии? Бедненький))
Оставьте свое сообщение

См. также

[Расширение] КоДан: Контроль ввода данных и доступа к данным [БП, УТ, ЗУП, УНФ, ERP] Промо

Роли и права v8 v8::Права Розница УНФ ERP2 БП3.0 УТ11 КА2 ЗУП3.x Платные (руб)

Расширение позволяет без изменения кода конфигурации выполнять любые проверки при вводе данных, а также скрывать от пользователя недоступные ему данные. Возможна настройка фильтров на вводимые данные с использованием СКД и выполнение произвольных действий над данными. Не требует снятия конфигурации с поддержки, может использоваться с любой конфигурацией на платформе 8.3.6 или выше.

3000 руб.

23.05.2015    104665    239    246    

Методика обновления формы объекта данных при изменении объекта

Практика программирования v8 v8::УФ 1cv8.cf Абонемент ($m)

В формах объектов данных часто встречаются элементы, косвенно связанные с объектом. Логику обновления этих элементов при изменении объекта обычно вызывают из обработчиков ПриСозданнииНаСервере и ПриОткрытии, забывая про наличие других способов изменения объекта. В статье предложена методика для обычных и управляемых форм, учитывающая все способы.

1 стартмани

09.03.2020    5906    0    tormozit    13    

СКД: красивые надписи в заголовках колонок

Практика программирования Работа с интерфейсом v8 v8::СКД УПП1 Россия Абонемент ($m)

Необходимо немного исправить вывод надписей в заголовках колонок, сделать более читаемый вариант. Как это сделать?

2 стартмани

27.02.2020    8457    7    wowik    36    

Делаем из СКД Excel (ну, почти)

Работа с интерфейсом v8 Абонемент ($m)

Несложный в использовании способ внедрить в обычный отчет СКД возможность редактировать значения ресурсов отчета (а-ля Excel) и получать отредактированные значения для дальнейшей обработки.

1 стартмани

26.01.2020    6743    9    herfis    16    

[Расширения] Динамическое управление видимостью и доступностью элементов форм (УФ) (8.3.6+) Промо

Сервисные утилиты Универсальные обработки Работа с интерфейсом v8 v8::УФ 1cv8.cf Платные (руб)

Механизм «Динамическое управление доступом к элементам форм объектов 1С8» предназначен для обеспечения возможности оперативного управления видимостью и доступностью элементов форм документов и справочников продуктов фирмы «1С» «1С:Предприятие 8». Решение универсальное, встраивается в любую конфигурацию с минимальными доработками, что позволяет без проблем обновлять типовые решения.

5000 руб.

14.01.2016    37671    9    10    

Индикация прогресса выполнения фонового задания на управляемой форме внешней обработки

БСП (Библиотека стандартных подсистем) Работа с интерфейсом v8 v8::УФ 1cv8.cf Абонемент ($m)

Внешняя обработка с фоновым выполнением и индикацией процесса для любой конфигурации на основе БСП >= 2.3 без изменения конфигурации и встраивания обработки в "Дополнительные отчеты и обработки".

1 стартмани

27.12.2019    7221    9    1sig    12    

Декомпиляция условного оформления

Работа с интерфейсом v8 1cv8.cf Абонемент ($m)

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

1 стартмани

23.12.2019    5925    29    XilDen    3    

Многоуровневые списки выбора с оформлением элементов

Практика программирования Работа с интерфейсом v8 v8::УФ 1cv8.cf Абонемент ($m)

Данная статья - попытка решить один маленький кусочек большой проблемы платформы 1С, а именно - бедные и невыразительные пользовательские интерфейсы. Поскольку 1С в режиме управляемого приложения позволяет задействовать веб-клиент, то хочется реализовывать интерфейсы как у взрослых веб-приложений - красивые, дружелюбные для пользователя и, желательно, с положительным UX. Возможно, кто-то со мной не согласится и скажет, что учетные системы должны быть строгие и линейные. Но мы все знаем, что 1С - это уже не только про бухгалтерию. Небольшое отступление для разработчиков, работающих с типовыми конфигурациями. Я не знаю, использует ли фирма 1С что-то похожее в своих разработках. Если да, то данная статья навряд ли будет вам полезна.

1 стартмани

17.12.2019    6389    2    azhilichev    5    

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

Работа с интерфейсом v8 ERP2 УТ11 Россия Абонемент ($m)

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

1 стартмани

09.09.2019    8733    10    bmk74    1    

[Взрыв шаблона!] Новый способ программной настройки условного оформления

Работа с интерфейсом v8::УФ 1cv8.cf Абонемент ($m)

Условное оформление форм и списков это великолепная возможность их настройки по заданным условиям. Но существенным недостатком является трудоемкость написания и сопровождения программного кода. В публикации предлагается новый способ программной настройки условного оформления.

1 стартмани

01.12.2019    9284    33    mszsuz    11    

"Живые" картинки со Snap.SVG

Практика программирования WEB Работа с интерфейсом v8 Абонемент ($m)

В статье рассмотрен пример использования http-сервисов для визуализации данных

1 стартмани

24.10.2019    12056    17    blackhole321    7    

Удобный выбор из таблицы/дерева в УФ

Практика программирования Работа с интерфейсом Разработка v8 v8::УФ 1cv8.cf Абонемент ($m)

Выбор из таблицы значений или дерева значений в выпадающем списке рядом с полем ввода - УФ, быстро и просто!

1 стартмани

12.08.2019    11029    6    Yashazz    18    

Модель объекта Промо

Инструментарий разработчика v8 Абонемент ($m)

Подсистема позволяет описать модель данных объекта, где описана зависимость между реквизитами, и затем использовать эту модель в разных сценариях работы с объектом. Версия платформы: 8.3.6 и выше. С небольшими доработками будет работать на 8.2.

1 стартмани

30.06.2019    10748    0    vadim1980    5    

[Механизм интерфейса] Свой флажок (чекбокс)

Работа с интерфейсом v8 1cv8.cf Абонемент ($m)

Создадим свой флажок для интерфейса, используем простой универсальный алгоритм.

1 стартмани

09.08.2019    13185    16    rpgshnik    42    

Отбор на управляемой форме из списка значений

Практика программирования Работа с интерфейсом Разработка v8 v8::УФ 1cv8.cf Абонемент ($m)

Пример простого удобного отбора любых данных ссылочного типа на управляемой форме. Работа обработки проверена на релизе: 1С:Предприятие 8.3.13.1513.

1 стартмани

09.08.2019    13705    17    nagaitseff    6    

Изменяющееся контекстное меню в 1С 8.3

Практика программирования Работа с интерфейсом Разработка v8 v8::УФ Абонемент ($m)

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

1 стартмани

06.08.2019    13583    2    signum2009    15    

Расширенная настройка динамического списка УФ Промо

Работа с интерфейсом v8 v8::УФ 1cv8.cf Абонемент ($m)

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

1 стартмани

31.05.2017    29886    146    tormozit    23    

Шпаргалка разработчика для работы с формами

Работа с интерфейсом v8 Россия Абонемент ($m)

Сборник помогает быстро освоить встроенный язык и средства конфигурирования при разработке обычных и управляемых форм.

3 стартмани

31.10.2018    14433    77    ELAM    3    

Рисуем и распознаем нарисованное при помощи нейросети

Практика программирования Работа с интерфейсом v8 v8::УФ 1cv8.cf Абонемент ($m)

Используем нейронную сеть для распознавания нарисованных объектов.

1 стартмани

03.10.2018    12820    43    DO_WHILE_LOOP    28    

Рисуем диаграммы в metadata.js

Инструментарий разработчика Работа с интерфейсом v8 v8::СКД 1cv8.cf Абонемент ($m)

Не одной же литературой заниматься?

1 стартмани

20.09.2018    14853    3    1c-intelligence    77    

Открывашка ячеек таблиц Промо

Работа с интерфейсом v8 1cv8.cf Абонемент ($m)

Глобальное сочетание клавиш для открытия объекта по ссылке из текущей ячейки любой таблицы в большинстве управляемых форм

1 стартмани

27.10.2018    14914    12    tormozit    31    

Визуализация событий на временной шкале средствами "Поле HTML документа"

Работа с интерфейсом v8 1cv8.cf Абонемент ($m)

Интересный способ наглядно отобразить события на временной шкале. Например, может быть применен для красивого вывода документов по клиенту. Тестировалось на платформе 8.3.12.1469

1 стартмани

31.07.2018    21372    135    Plotks2017    27    

Продвинутое рисование в табличном документе (стрелок и не только)

Практика программирования Работа с интерфейсом v8 Абонемент ($m)

Вспоминаем геометрию и основы компьютерной графики. Матрицы и аффинные преобразования на плоскости.

1 стартмани

24.07.2018    13469    18    WalterMort    29    

Полезный код для программистов 1С (часть 2). Помощник заполнения.

Практика программирования v8 Абонемент ($m)

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

1 стартмани

20.07.2018    14514    13    vandalsvq    14    

Лучший подарок для бухгалтера - счёты 8.2 (со звуком) Промо

Работа с интерфейсом v8 1cv8.cf Россия Абонемент ($m)

(Толстый клиент) Подарите бухгалтеру счеты, и он(а) Вас никогда не забудет.

1 стартмани

13.05.2011    38232    24    Tatitutu    45    

Работа с данными выбора

Практика программирования Работа с интерфейсом v8 Россия Абонемент ($m)

В управляемом интерфейсе заложена мощная возможность описывать связи реквизитов формы через параметры. Установка параметров связей позволяет ограничить выбор данных так, чтобы целостность данных была обеспечена на этапе ввода. Однако без дополнительного программирования задать можно только самые простые связи. Такие условия связи, как зависимость от реквизита через точку или зависимость через дополнительное отношение, заданное в регистре сведений - уже задать без программирования не получится.

1 стартмани

17.07.2018    38921    17    kalyaka    16    

Управление состоянием формы через конечный автомат

Практика программирования Работа с интерфейсом v8 Россия Абонемент ($m)

Взаимодействие пользователя с интерфейсом приводит к изменению состояния формы и её элементов. Элементы отражают текущее состояние формы через свойства: видимости, доступности, оформления, текста заголовка и т.д. Даже при небольшом количестве элементов количество возможных состояний формы может быть достаточно большим. Необходимость учета всех состояний формы порождает сложные алгоритмы настройки элементов. В статье рассматривается алгоритмическое решение перехода к состоянию формы с использованием функционального подхода на основе декларативного описания

1 стартмани

19.06.2018    14667    12    kalyaka    37    

Иерархическая диаграмма

Работа с интерфейсом v8 1cv8.cf Абонемент ($m)

Концепция диаграммы по иерархической структуре данных, например по номенклатуре (продажи или остатки на складах).

2 стартмани

17.06.2018    11942    16    DrAku1a    6    

Интерактивный интерфейс Промо

Рабочее место Работа с интерфейсом v8 1cv8.cf Россия Абонемент ($m)

Обработка (отдельная панель меню), позволяющая настраивать интерфейс пользователя интерактивно (права не настраивает). Мне очень пригодилось, так как приходится прописывать индивидуальный интерфейс, каждому пользователю (а их уже сотни). Выложил 2 версии одна в виде таблицы, вторая в виде выпадающего меню

1 стартмани

29.10.2011    16580    2    Vin_Tik    9    

Рисуем стрелки в табличном документе

Работа с интерфейсом v8 1cv8.cf Абонемент ($m)

Рисуем стрелки средствами 1С .

1 стартмани

01.06.2018    13717    8    pm74    9    

Работа со схемой запроса

Инструментарий разработчика Практика программирования v8 v8::Запросы Абонемент ($m)

Стандартом взаимодействия с реляционной базой данных стал язык SQL. Приемником SQL в 1С является язык запросов. Язык запросов, также как и SQL, является структурированным. Составляющие структуры запроса отвечают на разные вопросы о том, какие данные требуется получить и какие манипуляции с множествами данных необходимо произвести при получении. В простых случаях текст запроса можно написать вручную, однако в сложных случаях, а также при программном формировании, - лучше воспользоваться объектной моделью запроса и использовать объект "Схема запроса". В статье дается описание объектной модели и особенностей работы с ней, а также приводится решение, упрощающее взаимодействие с объектом "Схема запроса".

1 стартмани

24.04.2018    40719    85    kalyaka    34    

Шаблон MVC для управляемого интерфейса

Работа с интерфейсом v8::УФ 1cv8.cf Россия Абонемент ($m)

Мы воспринимаем как что-то само собой разумеющееся интуитивно понятный интерфейс, мгновенно реагирующий на наши клики, подстраивающийся под уже сделанный нами выбор. А между тем за этой возможностью - решение серьезных алгоритмических задач. В общем случае решения этих задач уже найдены, но проблема их конкретного применения остается как для выбранного окружения (веб-браузер, экран мобильного телефона, компьютер), так и возможностей языка программирования. В следующей статье представлено одно из таких применений общего решения на основе шаблона MVC для 1С в сочетании с возможностями управляемых форм и декларативного описания интерфейса.

1 стартмани

14.03.2018    18984    10    kalyaka    37    

Тестирование интерфейса в обычном приложении 8.2 при помощи SikuliX

Инструментарий разработчика Работа с интерфейсом v8 1cv8.cf Абонемент ($m)

Как же не хватает клиента тестирования на платформе 8.2. Не кликнешь на кнопку, не выберешь из списка, не проверишь видит ли надпись пользователь. Воспользуемся внешним инструментом SikuliX, который позволит нам протестировать функционал форм. Данный инструмент легко встраивается в линию сборки и может "дружить" с уже известным многим Open-source продуктами.

1 стартмани

03.01.2018    26947    3    kraynev-navi    41    

Программное формирование форматированной строки в стиле html+inline CSS

Работа с интерфейсом Инструментарий разработчика v8 1cv8.cf Абонемент ($m)

Если вам приходилось работать с форматированными строками программно, то вы знаете, какая это боль. Данное решение облегчает программное формирование таких строк.

1 стартмани

18.11.2017    28187    31    bonv    10    

Размеры управляемой формы

Практика программирования Работа с интерфейсом Универсальные функции v8 1cv8.cf Абонемент ($m)

Как рассчитать ширину и высоту управляемой формы или отдельного элемента, чтобы адаптировать интерфейс программно при их изменении.

1 стартмани

08.10.2017    25264    71    json    9    

Полезный код для программистов 1С (часть 1). Управление свойствами элементов формы. Хранение копии данных реквизитов

Инструментарий разработчика Практика программирования v8 Абонемент ($m)

У каждого программиста за время работы накапливается полезный инструментарий, которым он привык пользоваться. Естественно и у меня он тоже имеется. И вот решено было немного поделиться с сообществом. Возможно идеи не новые. Более того, допускаю, что реализованы они не самым оптимальным образом. Но ведь для этого сообщество и существует, чтобы делиться с ним, получая обратную связь.

1 стартмани

24.09.2017    39856    15    vandalsvq    80    

Программное создание элементов графической схемы (через XSLT)

Практика программирования Работа с интерфейсом v8 1cv8.cf Абонемент ($m)

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

1 стартмани

20.07.2017    18912    58    lazarenko    16    

Простой редактор плана помещения JavaScript

Практика программирования Работа с интерфейсом v8 1cv8.cf Абонемент ($m)

На ресурсе сейчас очень много решений, которые позволяют редактировать карты, используя географические схемы. Так же много решений, которые позволяют редактировать объекты онлайн веб-карт. Мне же нужно было простое решение, для того чтобы расставить квадратные объекты на плане, показать их пользователю. Ну и распечатать, опять же. Я решил написать простенький редактор на JavaScript с использованием библиотеки Raphael.

1 стартмани

23.11.2016    18967    90    igel9780    22    

Настройка начальной страницы (Рабочего стола)

Работа с интерфейсом Рабочее место Универсальные обработки v8 1cv8.cf Абонемент ($m)

Альтернатива стандартной настройке начальной страницы. В типовой доступны лишь те формы, что явно "разрешены" разработчиком в режиме конфигуратора. Эта обработка позволяет собрать "Рабочий стол" из любых подходящих форм в пользовательском режиме. Без программирования. БСП не используется. Не расширение. Универсальна, т.е. подойдет для любой конфигурации (в т.ч. самописной).

2 стартмани

19.10.2016    34485    211    Erne100    24    

[Расширение] Стартовые страницы. Автозапуск форм при старте 1С. (8.3.9+, без доработки конфигурации)

Инструментарий разработчика Работа с интерфейсом v8 1cv8.cf Абонемент ($m)

Уверен, что в большинстве случаев список справочников, отчетов, обработок (объектов 1С в целом), к которому обращаются пользователи после запуска конфигурации 1С, раз от раза меняется не сильно. Так почему бы немного не упростить процесс открытия часто используемых форм? Данное расширение позволяет настроить автоматическое открытие различных форм объектов сразу после запуска 1С. Список форм настраивается индивидуально для каждого пользователя. Работает на платформе 8.3.9, без доработки конфигурации.

1 стартмани

03.10.2016    19905    81    Artem-B    20    

HTTP-сервис: отчеты [Расширение]

Практика программирования Работа с интерфейсом v8 1cv8.cf Абонемент ($m)

Это HTTP-сервис, который возвращает почти любой отчет в HTML, XLSX или в JSON. Сохраните вариант отчета, получите на него ссылку и можно получить данные без захода в 1С. Работает в конфигурациях на основе БСП 2.3.3+, для отчетов на СКД и в 1С 8.3.8+

2 стартмани

30.08.2016    24164    130    Stepa86    15    

Блокировка баннеров при помощи расширения

Работа с интерфейсом v8 1cv8.cf Абонемент ($m)

Примеры использования расширений

1 стартмани

09.06.2016    12716    12    oslokot    16    

Простые радости жизни программиста 1С: выбор типа значения

Работа с интерфейсом Практика программирования v8 1cv8.cf Абонемент ($m)

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

1 стартмани

17.02.2016    45881    49    yuraos    17    

Визуальный редактор цветовых схем подсветки синтаксиса 1С + импорт схем Visual Studio

Работа с интерфейсом v8 1cv8.cf Абонемент ($m)

Данная обработка призвана облегчить настройку рабочего места программиста 1С, а именно улучшить визуальное восприятие кода, уменьшить утомляемость, и, как следствие, увеличить общую производительность труда!

1 стартмани

29.01.2016    14067    75    ram3    27