|
Запрет создания новых элементов справочника не подходящих под определенные критерии. | ☑ | ||
---|---|---|---|---|
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) Если справочник твой, то в модуле объекта, ПередЗаписью.
Если правишь типовую, то подписка. |
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |