Microsoft Dynamics AX 2012 White Paper: Introduction to the SysOperation Framework

[belugin]

Посмотрел.

У меня смена EDT и добавление методов отрабатывает после Tools\Caches\Refresh elements (нашел просто методом тыка сперва подумав где может быть)

Синтаксическим переименованием не пользовался. С полпинка не заработало - как с methodStr так и с просто вызовом - не мог бы ты проверить (у меня вот такой main):

static void main(Args _args)
{
    new SysOperationServiceController(classStr(TEST_HelloOp), methodStr(TEST_HelloOp, sayHello), SysOperationExecutionMode::Synchronous)
        .startOperation();
    new TEST_HelloOp().sayHello(new TEST_HelloContract());
}

Теперь про перекрестные ссылки (раз уж ты нарушил обет на обсуждение исследования исходного кода).

Дело в том что для RunBase есть совершенно та же сама проблема: когда мы встаем на Run и вызываем перекрестные ссылки, то мы видим
1) В типичном случае одну ссылку из метода main того же класса
2) Дерево наследования, которое по хорошему тоже надо просмотреть. (Так как run можно вызвать везде, где можно вызвать runbase.run и из наследников данного класса тоже)

У меня, в Ax6 187 таких ссылок (на runbase.run). Но это не является проблемой. Потому, что у нас есть априорное знание, что в типичном случае, мы вызываем наш RunBase и main этого же класса и + он вызывается из недр фреймворка при пакетной обработке. нам остается только проверить, что заданный случай сводится к типичному.

Для этого мы

1. Ищем ссылки на run нашего класса + всех нефреймворковых наследников и предков.
2. Ищем ссылки на наш класс и проверяем, что там где он создан, он никуда не передается,а вызывается prompt и run

Примерно по такой же схеме мы идем и в случае SysOperation - мы ищем ссылки на нашу операцию и убеждаемся, что дальше происходит только startOperation.

Если сделать перекрестные ссылки, которые сразу показывают код - достаточно 1 клика (см атач) в нашем случае.

Таким образом, у нас в этом вопросе нет существенной разницы между SysOperation и runbase - единственная разница в том, что к последней мы еще не привыкли.



По поводу копипаста

После копипаста надо еще не забыть переименовать. Один раз я долго тупил, пока не обнаружил, что в main вызывается другой класс. Еще была забавная ошибка, когда кто-то забыл добавить параметр "дата" в макрос для распаковки/упаковки и обнаружилось это только когда попробовали запихать класс в пакетное задание.

Еще недавно попробовал поискать на типичные ошибки копипасты в коде приложения конструкции типа

switch (x)
{
   case y:
   ...
   case y:
   ...
}

Нашел несколько явных ошибок в, казалось бы, оттестированном коде

[mazzy]

Цитата:

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

У меня смена EDT и добавление методов отрабатывает после Tools\Caches\Refresh elements (нашел просто методом тыка сперва подумав где может быть)

спасибо. посмотрю.

Цитата:

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

Синтаксическим переименованием не пользовался. С полпинка не заработало - как с methodStr так и с просто вызовом - не мог бы ты проверить (у меня вот такой main):

попробую позже. если время будет.

Цитата:

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

Теперь про перекрестные ссылки (раз уж ты нарушил обет на обсуждение исследования исходного кода).

э-э-э-э? что за обет?

Цитата:

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

Дело в том что для RunBase есть совершенно та же сама проблема: когда мы встаем на Run и вызываем перекрестные ссылки, то мы видим
...
Примерно по такой же схеме мы идем и в случае SysOperation

Не, ни фига.
в случае SysOperation мы НЕ видим.
Или можешь подсказать как найти "чем используется" метод TEST_HelloOp.SeyHello в твоем примере?
Если написать код c main как в примере, то как найти "чем используется" метод SayHello?

(кстати, я так и не понял как писать метод main для твоего примера. Можешь привести проект с main?)

[db]

Цитата:

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

Посмотрел.

У меня смена EDT и добавление методов отрабатывает после Tools\Caches\Refresh elements (нашел просто методом тыка сперва подумав где может быть)

Ругаться про нововведения надоело - так что будем изучать и пилить
Да, действительно кеш в\Classes\SysOperationAttributedDataContractInfo\buildDataMemberMaps

Лазить в Tools\Caches\Refresh elements каждый раз лень, а может непривычно (но не суть) - по сему добавил сброс кеша в инкрементную компиляцию.

\Classes\SysCompilerOutput\compileForwardElement

public static client void compileForwardElement(DictClass _dictClass, Dictionary _dictionary, int _numOfClasses)
{
    #AOT
    ClassNode           classNode;
    DictClass           dictClassLoop;
    DictClass           childClass;
    int                 i;

    if (_dictClass)
    {
        classNode = infolog.findNode(#ClassesPath + #AOTDelimiter + _dictClass.name());
        // SysOperationAttributedDataContractInfo cache reset -->
        classFactory.globalObjectCache().remove('SysOperationAttributedDataContractInfo.buildDataMemberMaps', [_dictClass.id()]);
        // SysOperationAttributedDataContractInfo cache reset <--
        
        if (classNode)
        {

можете прилепить еще куда нибудь или сделать отдельный пункт в контекстном меню. в данном варианте инкрементная компиляция контракта (не контроллера) чистит кеш

Дополнение. Наверное даже лучше добавить сброс кеша всех контрактов на окончание компиляции. Тормозов компиляции это не добавит, а кнопочка F7 всё таки приятнее контекстного меню
\Classes\SysCompilerOutput\endCompilation

.....
           this.setEndFocus();
        }
    }

    // Notify the editors to allow them to update markings
    CompileOutputInfos::NotifyChanges();
    classFactory.globalObjectCache().clear('SysOperationAttributedDataContractInfo.buildDataMemberMaps');
}

выбирайте кому что нравится