Имя: Пароль:
1C
 
Запрет создания новых элементов справочника не подходящих под определенные критерии.
0 Dunstan
 
26.03.19
20:45
Доброго времени суток!
Такая проблема:Запрет создания новых элементов справочника не подходящих под определенные критерии.
Элементы справочника могут создаваться как программно так и интерактивно.
Где прописать в ОДНОМ месте (как для программного так и интерактивного создания элементов справочника) код, который бы не давал создаваться либо записываться элементам справочника не подходящим под критерии?
1 Cyberhawk
 
26.03.19
20:52
В подписке на "ПриЗаписи"
2 Cyberhawk
 
26.03.19
20:53
Потому что в "ПередЗаписью" после твоей подписки с проверкой могут в будущем насоздавать еще подписок, которые будут выполняться уже после твоей проверки.
3 Cyberhawk
 
26.03.19
20:54
Ну а для интерактивного запрета, чтоб было все по чертежу - вызов той же самой проверки в обработке проверки заполнения
4 Garykom
 
гуру
26.03.19
22:29
(3) Двойная проверка при интерактивном?
5 palsergeich
 
26.03.19
22:31
(3) Можно, но зачем, все равно в призаписи попадешь.
6 Cyberhawk
 
27.03.19
08:41
(4) Не двойная - отлуп же взведется
7 Cyberhawk
 
27.03.19
08:41
(5) А оттуда можно вывести сообщения, чтоб они к интерактивчику подвязались (к полям формы)?
8 unregistered
 
27.03.19
09:02
В подписке ПередЗаписью объекта.

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

Аргумент из (2) - какая-то мутная история непонятно о чем. Как будто в ПриЗаписи никто другой никаких других проверок запилить не сможет. С этой точки зрения (наличия чьих-то дополнительных добавленных обработчиков) разницы между ПередЗаписью и ПриЗаписи нет никакой.

Муть про добавление лишних вызовов процедур проверок из формы - вообще какой-то избыточный бред.
Дублировать проверки или вызов проверок из формы имеет смысл (чисто теоретически), если есть возможность выполнить проверку на клиенте, не обращаясь к серверу, для некой экономии.
9 1Сергей
 
27.03.19
09:17
В интерактиве лучше сразу подсветить незаполненные, неправильно заполненные данные
10 Cyberhawk
 
27.03.19
10:47
Товарищу из (8) могу только предложить перечитывать (2) до наступления просветления :) Не каждому дано создавать надежные решения, это да. Ну и защитная реакция на устоявшуюся привычку срабатывает, вероятно
11 palsergeich
 
27.03.19
10:48
(7) можно.
12 palsergeich
 
27.03.19
10:52
Но с точки зрения технологичности, вариант с вызовом процедуры ОМ на форме и в призаписи, да лучше, не будут устанавливаться лишние блокировки транзакции, там где они не нужны
13 Nyoko
 
27.03.19
10:54
По хорошему делается так 2 модуля ПроверкаГраблиКлиент (для процедуры проверки в форме еще до попытки записи ) ПроверкаГраблиСервер (для подписки при записи, и главной процедуры проверки граблей) Проверку делает общая функция ПроверитьГрабли(СтруктураПараметров) в ПроверкаГраблиСервер
14 Eiffil123
 
27.03.19
11:19
(2) аналогично в будущем могут насоздавать подписки "ПриЗаписи". Преимуществ это не дает.
15 catena
 
27.03.19
11:21
(14)В ПриЗаписи не напихают изменений реквизитов. А в ПередЗаписью могут. И если подписка ПередЗаписью с новыми реквизитами отработает после подписки с проверками, может случиться конфуз.
16 Eiffil123
 
27.03.19
11:21
(7) Используй СообщениеПользователю. В синтаксис-помощнике прописан удачный пример использования.
17 Eiffil123
 
27.03.19
11:29
(15) да, логично.
Но в типовых проверки в основном идут в ПередЗаписью (и в ОбработкаПроверкиЗаполнения конечно же)
18 Вафель
 
27.03.19
11:35
в призаписи уже будет отмена транзакции, а в перед записью до транзакции не дойдет
19 Cyberhawk
 
27.03.19
11:37
(14) Не тупи, как (8): надежно (а Я вкладываю в это слово смысл "со 100% гарантией") реализовать отлуп вида "Ты не пройдешь" в ПередЗаписью нельзя, т.к. после проверки и _одобрения_ объект может быть еще изменен, а в ПриЗаписи - не может, так что насчет "преимуществ не дает" и "разницы нет" это ты погорячился.
Даже если кто-то решит написать *овнокод с получением и изменением объекта по ссылке в ПриЗаписи (после нашей проверки и одобрения), измененный объект все равно второй раз в ПриЗаписи прилетит и уже получит отлуп.
Плата за такую надежность (со 100% гарантией) - это потенциально ненужная запись объекта в БД, с этим не спорю.
20 Cyberhawk
 
27.03.19
11:40
(17) "в типовых проверки в основном идут в ПередЗаписью" // Это мина замедленного действия. Кто-то еще называет это "граблями", на которые наступить потом можно. Другое дело, что для принятия решения нужно знать соотношение затратности проверки и требуемой степени надежности.
21 mistеr
 
27.03.19
12:04
(0) Если справочник твой, то в модуле объекта, ПередЗаписью.

Если правишь типовую, то подписка.
2 + 2 = 3.9999999999999999999999999999999...