Цитата:
Сообщение от
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-классов перед непосредственной работой с таблицами?