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

[mazzy]

ГЫ!!!!!


создал свои классы по образцу. иcпользовал тип Name. Запустил. Получил Label = Name
Изменил тип Name на description везде.
Сделал инкрементную в CIL
запустил, получил все тот же Name.

Цитата:

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

1. Пекрестные ссылки работают

Не работают. Непонятно где именно происходит invoke.
об этом я уже отвечал Вадиму

Цитата:

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

3. Какие глюки?

Цитата:

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

4. Кроме устранения main есть еще устранение диалога/гетфромдиалога и пака/анпака

Вот что точно никак не мешало, так это пак/анпак. А диалог/гетфром все равно придется писать. Хотя бы чтобы по группам расставить. или в несколько колонок. (см. скриншот)



Ладно, я понял
Спасибо за конструктив.

Щас попробую еще повторить в виртуалке от Майкрософт. И закрою эту дверь.

[belugin]

Цитата:

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

Не работают. Непонятно где именно происходит invoke.

Я не очень понимаю, зачем знать, где происходит Invoke?

[belugin]

Цитата:

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

А диалог/гетфром все равно придется писать. Хотя бы чтобы по группам расставить. или в несколько колонок. (см. скриншот)

Прочитай, пожалуйста, хотя бы вводный простейший пример в вайтпейпере

[mazzy]

Цитата:

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

может я чего не понимаю?
может, кто-нибудь сможет объяснить: "ЗАЧЕМ они делают это?"
...
весь документ я прочитал. introduction перечитал несколько раз.
все равно - нуб и опозорился.

==========================

Цитата:

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

Я не очень понимаю, зачем знать, где происходит Invoke?

уже было.

Цитата:

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

я не про staticmethodstr
я про invokeStaticMethodIL, который выполняется в дальнейшем.

во-первых, они ВЫНУЖДЕНЫ делать assert для invoke.
во-вторых, invoke уже не ловится перекрестными ссылками. И встав мышкой на метод контролера мы НЕ узнаем, где же он вызывается. Нужен дополнительный и трудоемкий анализ.

[mazzy]

Цитата:

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

Щас попробую еще повторить в виртуалке от Майкрософт. И закрою эту дверь.

на недавно вышедшей виртуалке v2 переименование типов и добавление переменных - не работает. работает первая версия. импортированная или вбитая руками.
см. скриншот



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



до лучших времен

[belugin]

Цитата:

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

на недавно вышедшей виртуалке v2 переименование типов и добавление переменных - не работает. работает первая версия. импортированная или вбитая руками.

Посмотрю....

Цитата:

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

Желающие реализовали PurchFormLetter ( \Classes\PurchFormLetter\templateForm )

Цитата:

Мне кажется, мы просто уже привыкли к нашему блабу.

Блаба для нашего программиста вполне достаточно, так как он думает на Блабе.
?

[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?)

[belugin]

В принципе согласен:

Вариант 1. Мы инопланетяне, прилетевшие с планеты где не знают про RunBase и SysOperation

Для SysOperation нам надо посмотреть:
- перекрестные ссылки на метод
- перекрестные ссылки на DictClass.callObject
- и на \System Documentation\Classes\xApplication\runAsync
- и использование ключевого слова runAs

Для RunBase:
- перекрестные ссылки на MyClass.run
- перекрестные ссылки на RunBase.run

Собственно это проблема примерно одна и та же - наличия полиморфизма + передача по ссылке.

(представь себе, если б в runbase был метод

void startOperation()
{
  if (this.prompt)
  {
       this.run();
  }
}

)

НО!

В данном случае это проблемой не является - так как я вижу вызов startOperation сразу же за созданием контроллера и мне не важно где происходит кокретный callObjectMethod.

В-общем, это проблема полиморфизма + передачи ссылок. Только в случае runBase исследование кода легче для инопланетянина за счет того, что методы, которые планируются вызвать через RunBase явно принадлежат его подклассам.

Для неинопланетянина это примерно одно и то же для обоих фреймворков.

Пример прицепил (для нагладности запуск поместил в отдельный класс).

[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');
}

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