Аналог OnValidate в AX

[gl00mie]

Цитата:

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

В Nav при работе практически с любой таблицей (такой как "Customer" или "Item Journal Line"), можно было смело полагаться на триггеры уровня поля (OnValidate)

См. методы класса xRecord. У любой таблицы есть штатные методы validateField() и validateWrite(). Первый проверяет одно поле, второй - всю запись, они могут быть перекрыты на таблице, и там может быть навернута сколько угодно сложная логика проверки; по умолчанию, т.е. на уровне ядра поля проверяются по relation'ам (связам, прописанным в метаданных расширенных типов, используемых полями, и непосредственно таблиц), а запись проверяется на заполненность обязательных полей. Также ядро умеет проверять поля на соответствие дополнительным свойствам, прописанным в расширенных типах, вроде того, что числовое значение не должно быть отрицательным и т.п.

Цитата:

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

и уровня таблицы (OnInsert, OnModify) для того чтобы смоделировать кодом поведение пользователя вводящего данные вручную. Код в этих триггерах отвечал как за заполнение зависимых полей в текущей строке, так и за создание необходимых попутных записей в связанных таблицах.

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

Цитата:

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

Все что нужно было сделать для программного импорта данных это заполнять одно за одним поля и вызывать нужные тригерры в соответствующих местах.

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

Цитата:

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

Применима ли такая концепция к AX? И если да, то как можно узнать, в каких именно классах и методах хранится код подобный OnValidate, OnInsert и OnModify?

В Аксапте есть отлаженный механизм для программного создания и изменения записей таблиц без необходимости заморачиваться дерганием кучи триггеров и, главное, тем, в каком порядке заполнять поля таблиц. Это т.н. AxBC-классы; по соглашению об именовании они называются так же, как соотв. таблица, но с префиксом Ax, например, для InventTable - AxInventTable.
На мой взгляд, с точки зрения импорта всякого рода справочников использование этих классов - наиболее прямой путь, но есть, как всегда, нюанс: к сожалению, не для всех таблиц в Аксапте реализованы соотв. AxBC-классы, а если они и есть, то не всегда в них зашита вся необходимая логика. См. также обсуждение
В чем преимущество ax-классов перед непосредственной работой с таблицами?

[yuh]

Цитата:

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

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

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

Цитата:

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

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

[gl00mie]

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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