Вход | Регистрация
 

Запрет создания новых элементов справочника не подходящих под определенные критерии.

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

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

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

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

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


Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Рекламное место пустует