AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Программирование
DAX
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 05.06.2012, 20:40   #2  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5813 (201) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Цитата:
Сообщение от 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-классов перед непосредственной работой с таблицами?
За это сообщение автора поблагодарили: S.Kuskov (3), yuh (1).
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
emeadaxsupport: New Content for Microsoft Dynamics AX 2012 : October 2011 Blog bot DAX Blogs 0 27.10.2011 17:11
axinthefield: Dynamics AX Event IDs Blog bot DAX Blogs 0 01.03.2011 22:11
daxdilip: Whats New in Dynamics AX 2012 (A brief extract from the recently held Tech Conf.) Blog bot DAX Blogs 7 31.01.2011 12:35
axStart: Microsoft Dynamics AX 2009 Hot Topics Web Seminar Series Blog bot DAX Blogs 0 06.08.2008 12:05
Arijit Basu: AX 2009 - Quick Overview Blog bot DAX Blogs 4 19.05.2008 14:47

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 14:38.