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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 29.03.2016, 13:14   #1  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,867 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
? AIF vendTable.validateField() бага или фича ?
Привет.
Обнаружил в
\Data Dictionary\Tables\VendTable\Methods\validateField
странный код

X++:
boolean validateField(fieldId p1)
{
...
    boolean     ret;
    ;
    //AIFFault Mesgs
    switch (p1)
    {
        case fieldnum(VendTable, InvoiceAccount):
            if (this.InvoiceAccount && !VendTable::find(this.InvoiceAccount))
            {
                ret =  AifFault::checkFailedLogFault(strfmt("@SYS120870", fieldid2name(tablenum(VendTable), p1), this.InvoiceAccount), #InvalidInvoiceAccount);
            }
        break;
...
    }
//AIF Fault Mesgs end here
...
    ret = super(p1);

    if (ret)
    {
        switch (p1)
        {
...
            case fieldnum(VendTable, CreditMax) :
                if (this.CreditMax < 0)
                {
                    ret = checkFailed("@SYS69970");
                }
...
        }
    }
    return ret;
код процитирован для ax2009, но в 2012-й аналогично.

1. ret в начале метода никак не инциализируется, т.е. имеет значение false
2. Затем идет куча проверок для AIF с присвоением в ret значения false в случае ошибки.
3. Затем идет вызов super() c перетиранием значения ret (!) т.е. игнорируются найденные на шаге 2 некорректности в заполнении полей (хотя какие они найденные, когда ret инициализровался как false).
4. Затем обычные проверки значений полей.

Вопрос, что это такое ?
Это досадная опечатка в коде, приведшая к тому что не работает целый кусок по валидации значений (только пишет сообщения в инфолог и в AIF)
или так и было задумано (валидация в принципе на super() должна была отработать, но она только в инфолог сообщения шлет, а в AIF - нет. т.е. возможно этот код просто досылал интересующие автора сообщения в AIF) ?

Последний раз редактировалось Logger; 29.03.2016 в 13:31.
За это сообщение автора поблагодарили: S.Kuskov (2).
Старый 29.03.2016, 15:05   #2  
Link is offline
Link
Британский учённый
Аватар для Link
Соотечественники
 
568 / 513 (19) +++++++
Регистрация: 25.11.2005
Адрес: UK
Записей в блоге: 9
Судя по коду, значение ret перед super неважно. Т.е. в принципе присваивание ret до super можно убрать, что бы не вводить в заблуждение. Может копипаст такой.
__________________
Людям физического труда для восстановления своих сил нужен 7-8 часовой ночной сон. Людям умственного труда нужно спать часов 9-10. Ну а программистов будить нельзя вообще.
За это сообщение автора поблагодарили: Logger (1).
Старый 29.03.2016, 15:41   #3  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5788 (200) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Думаю, затея разработчиков AIF была примерно такая:
  • штатные проверки на обязательность заполнения полей и по relation'ам таблиц выводят подчас невнятные сообщения, типа значение "такое-то" не найдено в связанном справочнике сяком-то
  • программный код, в отличие от пользователя, с большим трудом по текстовому сообщению может понять, какую именно проверку не прошел поставщик, коду больше подходят некие уникальные идентификаторы ошибок
  • при создании/изменении поставщиков через AIF, в т.ч. с использованием Excel Add-in, очень важно понимать, в каком именно поле ошибка, а из сообщений это не всегда очевидно
Значит, решили разработчики AIF, надо продублировать проверки ядра и:
  • явно указывать, в каком поле ошибка
  • добавить некий уникальный идентификатор ошибки (см. библиотеку макросов #VendFaults)
Т.е. все перечисленные проверки для AIF, дублирующие проверки ядра, по сути нужны, чтобы добавить метку поля в текст ошибки и уникальный идентификатор ошибки - в контекст AifFault. За счет уникального идентификатора ошибки становится возможно "различать" в коде без интеллектуального разбора сообщений инфолога. А результат этих проверок действительно не важен, ведь они - лишь костылик для толкования и детализации результатов проверок в ядре.
Теги
aif, validatefield, vendtable

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
LookUp в SysQueryForm по TableRelations бага или фича Dreadlock DAX: Программирование 1 01.03.2012 12:10
daxdilip: How to: Configure Dynamics AX AIF Services to listen for SSL Requests (https) Blog bot DAX Blogs 0 23.01.2011 10:12
отключен RAsset = бага+фича Wamr DAX: Программирование 0 04.08.2009 22:46
update_recordset. Бага или фича? Lucky13 DAX: Программирование 7 08.04.2009 17:33
Бага или фича в модуле Расчеты с персоналом? katja DAX: Функционал 3 13.09.2004 18:10
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

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

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

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 01:16.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.