Комментарии 12
Напрасно вы ссылку даете на документацию с ограниченным доступом. Читатели будут справедливо недовольны.
Из плюсов - представленное решение понятно, просто и решает поставленную задачу. Конечно, реализация получилась очень частная, например, непонятно, как реализовать представление по нескольким полям.
Но сама реализация очень спорна с разных точек зрения. Например, заполнение поля "Альтернативное представление" для пользователя трудоёмко, правильно указать все эти ru, en и точки с запятыми в правильных местах - явно не задача пользователя. Напрашивается программное заполнение данного реквизита, чтобы форматирование происходило автоматически, но тогда поле не должно быть доступно в пользовательском режиме, а данные для его заполнения хранятся в нормальных полях "Английское наименование", "Российское наименование" и т.д. или в таблице соответствий Язык - Поле - Значение, например, Английский язык - Наименование товара - Метрические тонны.
Заполнение пользователями, видимо, приводит и к не очень хорошему коду. Попытка - Исключение сразу режут глаза, но, как я понимаю, это позволяет обойти ошибки заполнения. Тем не менее, такой код точно не прошел бы код-ревью. Нужно изменить архитектуру и избавиться от методов написания кода "оберну всё в попытку", чем грешат многие, закрывая ошибки проектирования. Заменить попытки как минимум нужно на проверку того, что содержится в параметре Данные (содержится ли ключ с нужным полем) + проверка корректности форматной строки.
Нужно изменить архитектуру и избавиться от методов написания кода "оберну всё в попытку", чем грешат многие, закрывая ошибки проектирования.
Интерфейс для ввода как я отметил там есть. Но если кто-то заполнит альтернативное представление (через обработку) другим кривым способом или не заполнит. Да сработает
Исключение Представление = Данные.СУУ_АльтернативноеПредставление; КонецПопытки;
Это больше защита от дурака
Не забывайте что эти стандартные обработчики срабатывают на каждую строку формы или отчета. Программа должна отрабатывать без ошибок в любом случае. Иначе получите 10500. Исключений на экран пользователя.
Да, я понимаю, что это стандартные обработчики. И в них никогда в стандартных конфигурациях не используется конструкция Попытка - Исключение. Вы видели такие примеры в коде типовых конфигураций, например, в этих обработчики? Вообще, конструкция Попытка - Исключение нужна в работе, когда мы имеем дело с транзакциями, например, или вызовом внешних сервисов, когда мы не можем гарантировать, как поведет себя система в тех местах, которые мы не контролируем. Если есть текстовое поле, которое мы даём ввести пользователю, и мы не можем его ограничить, чтобы оно было введено корректно и вынуждены ловить Попыткой ошибки - значит, что мы спроектировали что-то не так. К сожалению, повторюсь, такие вещи часто встречаются и в тиражных решениях (в конфигурациях Альфа-Авто, например) - и все эти места очень режут глаз и говорят о недоработанности решения.
Например, заполнение поля "Альтернативное представление" для пользователя трудоёмко, правильно указать все эти ru, en и точки с запятыми в правильных местах - явно не задача пользователя.
Там на скрине показана форма ввода пользователю формат строки соблюдать не нужно
Хорошо. Тогда в каких случаях мы ожидаем, что функция НСтр не сработает?
И в них никогда в стандартных конфигурациях не используется конструкция Попытка - Исключение. Вы видели такие примеры в коде типовых конфигураций, например, в этих обработчики? Вообще, конструкция Попытка - Исключение нужна в работе, когда мы имеем дело с транзакциями, например, или вызовом внешних сервисов, когда мы не можем гарантировать, как поведет себя система в тех местах, которые мы не контролируем.
Отвечу сразу на оба вопроса.
Типовые конфигурации нельзя считать образцом кода, хотябы по тому что на нескольких терабайт они просто сдохнут. Скорее архитектура в них это антипаттерн, вот свежий пример. А я их могу много накидать
Что делать, когда фоновые задания для печатных форм 1С тормозят? / Хабр (habr.com)
При построении архитектуры кода я каждую задачу смотрю с нескольких точек зрения, и выбираю тот стиль кода который удовлетворяет планируемой архитектуре.
Сколько точек зрения у Архитектора в ИТ? / Хабр (habr.com)
В данном случае - есть интерфейс ввода (кстати на общей форме) для ввода строки для Нстр , есть проверка на пустоту.
Но код универсален - он применяется не только в единицах измерениях, но и в других объектах. И я понимаю что справочник могут создать обработкой импорта, кривым представлением представлением без ru en . На эти редкие случаи и ставится Попытка Исключение
В целом у меня правило - любой код на каком то уровне оборачивается в Попытка Исключение . Либо идет запись в лог, либо обрабатывается разумным образом. Просто вылетающая программа это плохо - потом концов не найдешь.
и вынуждены ловить Попыткой ошибки - значит, что мы спроектировали что-то не так.
Это иллюзия что все можно спроектировать правильно, на всяких цепочках проведения и обработки, лучше записать проблему в лог в попытке исключения и идти дальше чем описывать все возможные реакции . Пользователи например при наличии 20 спецификаций на ПО уже поверхностно понимают как это считается внутри, хотя они должны детально знать свой бизнес процесс. По факту любой прикладной алгоритм содержит столько недосказанностей, что даже появились дисциплины типа Нечеткой логики
Что ж, если у Вас правило любой код заворачивать в Попытку - далее дискутировать бесполезно. Если интересно почитайте комментарии к статье https://infostart.ru/1c/articles/2053466/ и вообще литературу о таком подходе. И да, проблема большей частью не с производительностью кода в данном случае. И почему в загрузку обработкой нельзя добавить проверку - тоже не объясняете. А спроектировать правильно можно, это не иллюзия, было бы желание.
И почему в загрузку обработкой нельзя добавить проверку - тоже не объясняете
Потому что тогда нужно эту проблему контролировать в нескольких местах. Это трудно потом сопровождать.
Здесь реализован корректный вывод который не стопорит основную работу.
Помните что на каждый паттерн есть антипаттерн нет понятия правильный паттерн. Есть только best practice и здравый смысл
Сразу видно когда человек не разобрался в задаче.
Ваше решение будет работать на базе в тысячу строк.
В реальности - никаких сотен запросов к базе нигде нет, потомучто все динамические списки и отчёты - выводят не ссылку, а представление на нужном языке, т.е. сам реквизит где хранится нужный язык.
а представление сделано для случаев когда нет запроов - например в самих документах, в таблицах и т.д.
Так что надеюсь что никто вашему совету не последует.
Вы читали документацию на ИТС? Если нет - она на картинке выше. К сожалению в Вашем тексте мухи съели котлеты и превратились в фарш. Поэтому отделю
а) Любое обращение к базе возвращает выборку, при получении выборки обработчики представления еще не задействуются.
б) Обработчики задействуются только когда идет обращение к представлению - а именно отображение в списках например. Т.е. он срабатывает на ограниченное количество записей
Далее если почитаете про поиск в динамическом списке , там есть интересный эффект
Который подтверждает мои слова.
А так еще проще - возмите профайлер и посмотрите что генерит субд в по операторам . На уровне запросов к бд там проблем нет. Единственная проблема которая может быть - это когда Вы в обработчике представлений делаете соединения с другими таблицами, там да будет плохо. Но об этом есть предупреждение в документации и я так не делаю СУУ_АльтернативноеПредставление предусмотрительно в той же таблице по которой меняется представления.
Поэтому для большой базы при указанном применении представления проблем не будет
Трудности перевода