В практике разработки на платформе 1С:Предприятие 8.3 программисты постоянно сталкиваются с необходимостью изменения поведения форм документов, справочников и обработок. Давайте разберем, какие события модифицируются чаще всего, почему именно они, и какие существуют современные стандарты написания кода для этих задач.
Безусловным лидером, с которым нам приходится работать чаще всего в управляемых формах (УФ), является событие ПриСозданииНаСервере. В отличие от обычных форм, где "королем" было событие ПриОткрытии, в управляемом приложении логика сместилась на сервер.
Почему именно это событие?
Главная причина кроется в архитектуре управляемого интерфейса. Процедура ПриСозданииНаСервере — это единственный штатный момент времени, когда мы можем программно изменять структуру формы:
Попытка выполнить эти действия в других событиях (например, при чтении или открытии) приведет к ошибкам или игнорированию изменений платформой. Рассмотрим пример того, что обычно происходит внутри этого обработчика:
&НаСервере
Процедура ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)
// Программное добавление элемента
НовыйЭлемент = Элементы.Добавить("МояКнопка", Тип("КнопкаФормы"), Элементы.КоманднаяПанель);
НовыйЭлемент.ИмяКоманды = "МояКоманда";
// Установка начальных значений, зависящих от параметров открытия
Если Параметры.Свойство("ВажныйПараметр") Тогда
// Логика инициализации
КонецЕсли;
КонецПроцедуры
Хотя ПриСозданииНаСервере используется чаще всего, мы не должны забывать о событии ПриЧтенииНаСервере. Это распространенная ошибка новичков — размещать всю логику инициализации только при создании формы.
Давайте проанализируем разницу:
ПриСозданииНаСервере вызывается один раз при инициализации формы.ПриЧтенииНаСервере вызывается каждый раз, когда объект перечитывается из базы данных (например, после записи или при нажатии кнопки "Перечитать").Если видимость или доступность ваших элементов формы зависит от значений реквизитов объекта (например, "если статус документа = Закрыт, то скрыть кнопку"), эту логику необходимо дублировать или выносить в ПриЧтенииНаСервере. Иначе, если пользователь перечитает объект, данные обновятся, а интерфейс останется старым.
Сегодня редактирование типовых форм "в лоб" считается дурным тоном, так как это затрудняет обновление конфигурации. Мы должны использовать механизм расширений конфигурации. Для события ПриСозданииНаСервере существует важное правило использования аннотаций.
Рекомендуется использовать аннотацию &После. Это гарантирует, что типовой код инициализации формы отработает корректно, подготовит все структуры данных, и только потом вмешается наш код.
&НаСервере
&После("ПриСозданииНаСервере")
Процедура Расш1_ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)
// Здесь безопасный код добавления наших элементов
// Типовая форма уже сформирована
КонецПроцедуры
Использование аннотации &Вместо на этом событии крайне опасно. При обновлении типовой конфигурации логика инициализации может измениться, а ваше расширение продолжит выполнять устаревший код, что может полностью сломать работу формы.
В типовых конфигурациях (ERP, ЗУП, УТ, Бухгалтерия) разработчики 1С предоставляют нам специальные механизмы, чтобы мы могли встраивать свой код, не затрагивая сами формы объектов. Давайте посмотрим на общий модуль МодификацияКонфигурацииПереопределяемый.
В процедуру ПриСозданииНаСервере этого модуля часто передается контекст создаваемой формы. Это позволяет реализовать "единую точку входа" для модификации всех форм в системе. Например, если нам нужно установить отбор во всех динамических списках документов определенного типа, удобнее сделать это здесь, а не создавать расширения для каждой формы отдельно.
Помимо серверных событий, мы часто дорабатываем клиентскую часть для улучшения взаимодействия с пользователем:
Подводя итог нашему анализу, можно выстроить следующую иерархию частоты и важности событий:
&После.