Аналог OnValidate в AX

[oip]

table.validateField(), table.modifiedField(), table.validateWrite(), table.insert() и пр.

Если программист сделал все грамотно и не забыл написать нужный код куда следует и наверняка только в той части, в которой применима к NAV (то есть, думать все равно надо)... Принципиально от NAV отличаться не должно. Есть еще AX* классы, но я сомнвеваюсь, что в кастомизируемом (да и в стандартном) коде эта концепция везде поддерживается и на нее можно полагаться. Не поддерживается. Нельзя.

Только надо не забывать, что методы перекрыты бывают не только на уровне таблиц, но и на уровне источников данных форм. А иногда и на конкретных контролах.

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

Не поверю, что в NAV чтобы создать запись в "Item Journal Line" (и других таблицах) всегда достаточно написать так (псевдокод).

'Item Journal Line'.field1 := 1
'Item Journal Line'.onValidateField1()
'Item Journal Line'.field2 := 2
'Item Journal Line'.onValidateField2()
'Item Journal Line'.field3 := 3
'Item Journal Line'.onValidateField3()
...
'Item Journal Line'.OnInsert()
'Item Journal Line'.insert()

[yuh]

Цитата:

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

Не поверю, что в NAV чтобы создать запись в "Item Journal Line" (и других таблицах) всегда достаточно написать так (псевдокод).

'Item Journal Line'.field1 := 1
...

Олег, спасибо за ответ! Я когда это прочитал, чуть было сам не засомневался. А потом еще раз подумал и утвердился: да, именно так и происходит в NAV! Мало того, именно этот код используется самой системой при создании складских проводок из других модулей. Например, когда пользователь проводит продажу товара, программа создает специальный "временный" товарный журнал и заполняет его с помощью тех самых "OnValidate", а потом автоматически его разносит.
Отсюда - другой вопрос: а как это происходит в AX? Нечто подобное? И если да, то какие именно классы используются для создания журналов?

[oip]

Цитата:

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

Отсюда - другой вопрос: а как это происходит в AX? Нечто подобное? И если да, то какие именно классы используются для создания журналов?

Например, вот набросок кода создания журнала платежей для какой-то старой версии Аксапты:

void createIncomingJournal()
{

LedgerJournalNameId incomingName;
LedgerJournalTable incomingJournal;

ledgerJournalTrans incomingTrans;
ledgerJournalTrans ledgerJournalTrans;

LedgerJournalEngine ljeIn;
LedgerJournalEngine ledgerJournalEngine;

NumberSeq numSeq;
ProjTable projTable;
RContractTable rct;
RContractPartnerType rctType;

;

ttsbegin;
select forupdate incomingJournal;
incomingJournal.clear();
incomingJournal.initValue();
incomingJournal.JournalName=incomingName;
incomingJournal.insert();

ljeIn = new BMLedgerJournalEngine(null);
ljeIn.newJournalActive(incomingJournal);

if(ljeIn)
{
while select lines
    {
        ledgerJournalTrans=incomingTrans;
        ledgerJournalEngine=ljeIn;
        select forupdate ledgerJournalTrans;
        ledgerJournalTrans.clear();

        ledgerJournalTrans.TransDate=lines.PaymDate;
        ledgerJournalTrans.currencyCode=lines.CurrencyID;
        ledgerJournalTrans.ExchRate=lines.ExchRate;

        ledgerJournalTrans.initValue();
        ledgerJournalTrans.JournalNum=incomingJournal.JournalNum;
        ledgerJournalEngine.numberSeqFormHandlerJournal().parmLedgerJournalTrans(ledgerJournalTrans);
        ledgerJournalEngine.formMethodDataSourceCreatePost();
        ledgerJournalEngine.initValue(ledgerJournalTrans);

        ledgerJournalTrans.TransDate=lines.PaymDate;
        ledgerJournalTrans.currencyCode=lines.CurrencyID;
        ledgerJournalTrans.ExchRate=lines.ExchRate;

        ledgerJournalTrans.accountType=lines.AccountType;
        ledgerJournalTrans.AccountNum=lines.Account;
        ledgerJournalTrans.offsetAccountType=lines.offsetAccountType;
        ledgerJournalTrans.OffsetAccount=lines.offsetAccount;

        if(AmountDebit)
            ledgerJournalTrans.AmountCurDebit=lines.AmountDebit;
        else if(AmountCredit)
            ledgerJournalTrans.AmountCurCredit=lines.AmountCredit;

        ledgerJournalTrans.Txt=lines.TransTxt;
        ledgerJournalTrans.DocumentNum=lines.DocumentNum;
        ledgerJournalTrans.DocumentDate=lines.PaymDate;

        ledgerJournalTrans.validateWrite();
        ledgerJournalEngine.preWrite(ledgerJournalTrans);
        ledgerJournalEngine.formMethodDataSourceWritePre();
        ledgerJournalTrans.write();
        ledgerJournalEngine.write(ledgerJournalTrans);
    }
}
ttscommit;
if(ljeIn)
    info(strfmt("Создан журнал входящих платежей %1", incomingJournal.JournalNum));
}

Но тут повезло, что был класс BMLedgerJournalEngine. В общем, еще раз повторю - бизнес логика может быть и на форме и в этом случае будут вызываться не только табличные триггеры. Ну вот разве в NAV не так? Обратите внимание на вызов различных "formMethod". Некоторые из подобных классов без открытия формы и не инициализируешь.

Цитата:

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

Олег, спасибо за ответ! Я когда это прочитал, чуть было сам не засомневался. А потом еще раз подумал и утвердился: да, именно так и происходит в NAV!

Поспрашивал коллег, занимающихся NAV. У них другое мнение. В сферическом идеальном случае да, вызывать табличные триггеры достаточно. Но так это и в AX так. А в реальности бывает и код на формах, который при вызове табличных триггеров, естественно, не сработает.

[yuh]

Цитата:

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

Поспрашивал коллег, занимающихся NAV. У них другое мнение.

Ну вот, а я бросился было искать мануалы, научающие девелоперов всегда располагать код бизнес-логики в таблицах; при программном создании записей всегда вызывать OnValidate, OnInsert и OnModify;...
По крайней мере, так нас учили раньше и гордо называли это "Navision Way".
Может, с выходом более поздних версий что-то поменялось, и теперь этот путь уже не такой прямой