Использование проверки реквизита табличной части в модуле объекта.
Суть вопроса в следующем: формируется документ, и существует вероятность что в одну из колонок табличной части могут попасть пробельные символы вместо пустой строки. В процедуре формирования документа (это в объекте обработки) я делаю проверку
Так же для полной уверенности и поддержке принципа инкапсуляции ))), что в этой колонке не могут находится только пустые символы продублировал данный код в событии передЗаписьюОбъекта()
Коллега проверяющий мой код. Данный подход заброкавал, потому что это замедлит запись документов. И утверждение было в следующем, что правильное заполнение должно проверяться не при записи, а именно при формировании объектов.
я же исхожу из того принципа , что не сегодня-завтра другой программист не осведомленный о данной особенности этой колонки (а она должна быть обязательна очищена!!!) может формировать документ хоть во внешней обработке, хоть при обмене данными, не учтет этого и начнутся ошибки.
Интересно ваше мнение коллеги. Имеет ли смысл делать такие двойные проверки? И при заполнении документа и при записи оного? (конечно всегда нужно делать поправку на производительность и оптимизацию).
P.S. Прошу прощения за столь примитивный вопрос. Просто интересует общественное мнение ;)
СтрокаТабличнойчасти.Колонка1 = СокрЛП(СтрокаТабличнойчасти.Колонка1)Так же для полной уверенности и поддержке принципа инкапсуляции ))), что в этой колонке не могут находится только пустые символы продублировал данный код в событии передЗаписьюОбъекта()
Коллега проверяющий мой код. Данный подход заброкавал, потому что это замедлит запись документов. И утверждение было в следующем, что правильное заполнение должно проверяться не при записи, а именно при формировании объектов.
я же исхожу из того принципа , что не сегодня-завтра другой программист не осведомленный о данной особенности этой колонки (а она должна быть обязательна очищена!!!) может формировать документ хоть во внешней обработке, хоть при обмене данными, не учтет этого и начнутся ошибки.
Интересно ваше мнение коллеги. Имеет ли смысл делать такие двойные проверки? И при заполнении документа и при записи оного? (конечно всегда нужно делать поправку на производительность и оптимизацию).
P.S. Прошу прощения за столь примитивный вопрос. Просто интересует общественное мнение ;)
По теме из базы знаний
- Быстрый поиск дублей с четким/нечетким поиском по любому сочетанию реквизитов/реквизитов таб. частей с отбором и быстрой заменой значений в ЛЮБЫХ базах 8.1-8.3 (УТ 10.3, БП 2, ЗУП 2.5, КА 1.1, УТ 11, БП 3, УНФ 1.6/3.0, КА 2, ЗУП 3 и т.д.)
- Универсальное заполнение табличных частей
- Обзор полезных методов БСП 3.1.4
- Как читать чужой код? Часть 1. Общие вопросы. Доработка чужого кода. Code review
- Шаблоны новых объектов 1С для 1С:Бухгалтерии предприятия
Где нужно проводить проверку реквизитов объекта и его табличной части.
Всегда нужно проверять при заполнении реквизитов данными. (0%, 0 голосов)
0%
Проверять нужно в самом объекте При/перед записью. Но смотреть на производительность проверки. (50%, 3 голосов)
50%
По возможности использовать оба варианта (33.33%, 2 голосов)
33.33%
Другое.... (16.67%, 1 голосов)
16.67%
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Коллега проверяющий мой код. Данный подход заброкавал, потому что это замедлит запись документов.
Те сотые (а скорее тысячные) доли процентов замедления вряд-ли кто-то когда-то заметит. Уверен - если посмотреть модуль записи\проведения документа - там можно найти миллион строк кода который можно\нужно рефакторить для ускорения записи\проведения .
Проблема тут скорее в самом подходе, что это за строковой реквизит такой в котором так критичны пробелы? (вот явно, что-то не то в датском королевстве)
Это говорит о том, что кто-то когда-то создал костыль, который теперь заставляет этот костыль "правильно" обрабатывать. Если разберетесь, зачем нужна именно пустая строка и недопустимы пробелы, табуляции или еще что, исправите это, - вот тогда "и заживете!" )))
Да. Коллеги. Вы правы, что решение костыльное. Но в данном вопросе не хотел бы заострять внимание почему нужна именно пустая строка. Ведь может понадобиться и другая более ресурсоемкая функция. Например проверка суммы в строке. Так вот вопрос и в том.,следует ли перепроверять сумму по строке дополнительно в модуле самого объекта
(4) если уж необходима такая проверка, то для этого существует специальный обработчик. Так и называется ОбработкаПроверкиЗаполнения.
Правда в нем есть свои особенности.
С другой стороны в типовых конфигурациях на обычных формах распространено проверять вообще в обработчике ОбработкаПроведения.
На УФ все же перенесли проверки в ОбработкаПроверкиЗаполнения.
Правда в нем есть свои особенности.
С другой стороны в типовых конфигурациях на обычных формах распространено проверять вообще в обработчике ОбработкаПроведения.
На УФ все же перенесли проверки в ОбработкаПроверкиЗаполнения.
(5)спасибо за ответ. Кстати мне надо как то переписать вопрос. Тут я делаю не то что проверку а переприсвоение. И да. Имеет смысл сделать при проведении,а не при записи. Но вопрос все таки в другом. Следует ли выполнять дополнительные действия к приведению правильности данных в самом объекте, ведь мы можем проверять и перезаполнять данные на форме. Или где нибудь ещё, когда мы проводим заполнение.
Господа, действительно,есть в моих рассуждениях ошибки.
Лучше использовать данный механизм в обработчике при проведении. Для того, что бы ничего не обрабатывалось например при пометке на удаление.
Вторая моя ошибка: я использовал функцию СокрЛП() для того что бы в последующем в запросе использовать условие:
По православному правильнее в табличную часть добавить реквизит типа булева и заполнять его в зависимости от того, что вернет функция
или
Естественно тоже смотреть на сколько сильно затормозиться проведение документа. В данном случае вообще не сильно, но вместо этих функций может быть и более тяжеловесные.
P.S. Прошу прощения за использование термина "инкапсуляция". Здесь немного другое ))
Лучше использовать данный механизм в обработчике при проведении. Для того, что бы ничего не обрабатывалось например при пометке на удаление.
Вторая моя ошибка: я использовал функцию СокрЛП() для того что бы в последующем в запросе использовать условие:
ГДЕ ДокументТабличнаяЧасть.Колонка1 = ""По православному правильнее в табличную часть добавить реквизит типа булева и заполнять его в зависимости от того, что вернет функция
ЗначениеЗаполнено(СтрокаТабличнойчасти.Колонка1)
или
ПустаяСтрока(СтрокаТабличнойчасти.Колонка1)Естественно тоже смотреть на сколько сильно затормозиться проведение документа. В данном случае вообще не сильно, но вместо этих функций может быть и более тяжеловесные.
P.S. Прошу прощения за использование термина "инкапсуляция". Здесь немного другое ))
Так же конечно можно использовать обработчик ОбработкаПроверкиЗаполнения. Но данный обработчик НЕ вызывается при проведении документа например из внешней обработки.
Хотя в этом есть свой смысл.
Когда разработчик внешней обработки не уверен в корректности заполненных данных, ему нужно вызвать процедуру объекта ПроверитьЗаполнение()
Но тогда не совсем правильно делать не только проверки , но и перезаполнение реквизитов.
Хотя в этом есть свой смысл.
Когда разработчик внешней обработки не уверен в корректности заполненных данных, ему нужно вызвать процедуру объекта ПроверитьЗаполнение()
Но тогда не совсем правильно делать не только проверки , но и перезаполнение реквизитов.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот