Аналог OnValidate в AX

[yuh]

Цитата:

Сообщение от gl00mie

А если надо установить значение поля А, затем - поля Б, но триггер на изменении поля Б перезатрет значение поля А, которое связано с Б, при том что никто не просил его это делать?

Я думаю, что случай с перезатиранием значений полей страшен только когда мы бессистемно подходим к заполнению записи.
Скажем, мы заполняем журнал для ввода складских остатков. Пример двух зависимых полей - код товара и его стоимость (в простейшем случае, хранится как признак товара в соответствующей записи). Если мы сначала заполним стоимость а потом вернемся и введем код товара, то вполне можно ожидать что система затрет введенное нами значение тем, что записано в справочнике. Но мне кажется что ключ здесь в эмуляции действий пользователя при создании журнала вручную: естественно, что пользователь сначала выбирает товар - и только затем меняет стоимость на требуемую. Значит и наш код должен заполнять поля в том же порядке!

Цитата:

В Аксапте есть отлаженный механизм для программного создания и изменения записей таблиц без необходимости заморачиваться дерганием кучи триггеров и, главное, тем, в каком порядке заполнять поля таблиц. Это т.н. AxBC-классы

Спасибо за наводку, нужно будет попробовать этот подход. Надеюсь, "перезатирание" здесь побеждено.

[gl00mie]

Цитата:

Сообщение от yuh

Я думаю, что случай с перезатиранием значений полей страшен только когда мы бессистемно подходим к заполнению записи.
Скажем, мы заполняем журнал для ввода складских остатков. Пример двух зависимых полей - код товара и его стоимость (в простейшем случае, хранится как признак товара в соответствующей записи).

А вот зачем мне как программисту, пишущему тот же импорт, заморачиваться тем, какие между полями зависимости? Код товара и стоимость - это слишком простой пример, но ведь зависимости могут быть и куда затейливей, и без ковыряния в коде их подчас не выявить. Например, среди прочего в журнале может быть поле с кодом м... того же склада, и допустим, что у нас есть разделение по товарам, которые могут находиться на том или ином складе. При изменении кода склада проверяется, допустим ли указанный код номенклатуры, и если нет, он затирается, чтобы пользователь выбрал другой из списка доступных для склада (причем затирается все молча - точно так же, как молча затирается, скажем, договор при смене кода контрагента). Тот же программный импорт может быть совершенно не в курсе, что есть такой вот наворот, и сперва прописывать код номенклатуры, потом цену, а потом уже склад. На сохранении записи получим ошибку, что, мол, код номенклатуры не задан (он был стерт при прописывании склада) - и иди потом, ковыряйся, какого фига не задан, если есть и данные, и код, который эти данные в запись прописывает. Как можно заранее предусмотреть, что есть такие зависимости или что они появятся в будущем?

Цитата:

Сообщение от yuh

Если мы сначала заполним стоимость а потом вернемся и введем код товара, то вполне можно ожидать что система затрет введенное нами значение тем, что записано в справочнике.

С т.з. пользователя - да, с т.з. программного импорта, у которого есть на входе значения определенных полей, - нет. Те значения, которые код явно прописывает в запись, не должны перезатираться, потому что они известны и получены, не важно откуда, в явном виде, при этом корректны ли сочетания соотв. значений - это дело десятое. Вот те поля, которые не были явно инициализированы, бизнес-логика, связанная с той или иной таблицей, пусть заполняет, как хочет.

Цитата:

Сообщение от yuh

Но мне кажется что ключ здесь в эмуляции действий пользователя при создании журнала вручную: естественно, что пользователь сначала выбирает товар - и только затем меняет стоимость на требуемую. Значит и наш код должен заполнять поля в том же порядке!

Пользователя можно средствами презентационной логики принудить заполнять поля в определенном порядке, а принудить программиста заполнять поля записи в определенном порядке уже куда сложнее, особенно если это сторонний программист, пишущий интеграцию через Business Connector. Более того, сегодня порядок заполнения полей пользователем может быть один, завтра - другой, потому что поменялись зависимости между полями. Поменять поведение пользователя за счет ограничений, накладываемых презентационной логикой, очень просто, а вот что делать с кучей кода, создающего записи в таблице программно? Каждый раз искать его и переписывать - менять порядок заполнения полей? Абсурд...
В этом плане те же AxBC-классы очень грамотно сделаны: накидал полей, дернул один метод - и подтянулись все возможные связанные поля, не перезатирая те, которые заданы явно, "извне". При этом всегда можно понять, какие поля вообще заданы - извне либо изнутри, за счет логики самого класса. В этом случае действия пользователя по заполнению полей одного за другим - это лишь частный случай общей схемы работы (накидали значений полей - дернули обработчик), только значения полей пользователь всегда накидывает по одному.