AX2012. Цель атрибутов в расширении наследования классов

[ta_and]

Цитата:

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

Development tutorial: SysExtension framework in factory methods where the constructor requires one or more arguments
http://kashperuk.blogspot.co.uk/2017...extension.html

Спасибо. Очень дельная статья. Ответ на мой третий вопрос.

[mazzy]

спасибо )

Что мог бы сделать вендор: Extension Methods.

c# https://docs.microsoft.com/en-us/dot...ension-methods
Котлин https://kotlinlang.org/docs/reference/extensions.html

Вот это был бы настоящий и очень хороший extension.
Но вендор решил иначе.

[belugin]

Extension methods есть в Ax7 и они тут ни при чем. Это просто синтаксический сахар для вызова статических методов. Есть даже подобие companion objects в котлине

[mazzy]

именно!
синтаксический сахар.
именно для вызова статических методов.

я имел в виду "мог бы сделать Extension Methods вместо атрибутов для создания экземпляров классов". извините, что плохо сформулировал.
тем более, что уже реализовал. но нет, используются совершенно левые атрибуты.

Цитата:

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

и они тут ни при чем.

?!

как скажешь. бог с тобой.

[belugin]

Цитата:

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

я имел в виду "мог бы сделать Extension Methods вместо атрибутов для создания экземпляров классов".

Они никак не помогут в деле создания extensions - куда вставлять их вызов

[mazzy]

Вместо безумной конструкции
SysExtensionAppClassFactory::getClassFromSysAttribute

Вместо отдельно стоящих атрибутов и системного класса с принудительно-общей логикой дать возможность создавать свои фабрики. Продумать унификацию с экстеншенами форм и менюитемами. При этом не забыв о правах.

Насыпать сахара, который предоставлял бы дефолтное поведение по-умолчанию.

Да много чего можно было бы сделать. И для этого не нужен был жесткий алгоритм, задействующий рефлекшен.

[belugin]

Цитата:

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

Вместо отдельно стоящих атрибутов и системного класса с принудительно-общей логикой дать возможность создавать свои фабрики. Продумать унификацию с экстеншенами форм и менюитемами. При этом не забыв о правах.

Так экстеншены классов-то тут не причем (в том смысле, в котором экстендятся формы) - тут новые классы создаются, а не экстендятся старые.

Цитата:

Насыпать сахара, который предоставлял бы дефолтное поведение по-умолчанию.

Какой сахар нужен? Там и так минимально - помечашь класс аттрибутом. Для вызова ровно один метод. На мой вкус он назван не очень удачно, но вполне себе удобно вызывается.

Чего, как мне кажется не хватает, это вожможномсти посмотреть все экстеншены с ключами и валидации.

Цитата:

Да много чего можно было бы сделать. И для этого не нужен был жесткий алгоритм, задействующий рефлекшен.

Дык фреймворк добавить проще чем менять компилятор. Я просто не вижу чтобы тут был какая-то большая проблема

[mazzy]

Цитата:

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

Так экстеншены классов-то тут не причем (в том смысле, в котором экстендятся формы) - тут новые классы создаются, а не экстендятся старые.

ох, похоже, надо выделять в новую тему и рисовать схему...

Цитата:

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

Какой сахар нужен? Там и так минимально - помечашь класс аттрибутом. Для вызова ровно один метод.

именно!

какая потребность есть у людей в Аксапте:
= изменить или добавить функционал, который могут использовать пользователи
== пользователи работают с функционалом через menuItem
== menuItem вызывает классы через статический метод main (menuItem также используются для вызова форм)
== права доступа к функционалу Аксапты настраивается через menuItem

Вызывать класс напрямую вообще говоря моветон в Аксапте (хоть МС делает это сплошь и рядом в стандартном функционале, сволочи)
Если вызывать напрямую, то нужно запрограммировать закат солнца вручную чтобы учесть настроенные права.
Функционал аксапты можно и должно вызывать через menuItem.

что делает МС, чтобы удовлетворить потребность людей?
никакого сахара для работы с инфраструктурой аксапты
минимализм и совершенно перпендикулярная остальной инфраструктуре технология атрибутов

ну и так далее.
Макс, участники, я знаю что технология атрибутов работает. Спасибо, что вы рассказываете и даете ссылки на документацию.
Но я хотел сказать, что выбранный способ реализации - далеко не единственный. И далеко не оптимальный. Даже с тупой точки зрения выживания продукта.
Просто никто не думал о том, как ЭТО будут использовать конечные потребители - в данном случае разработчики партнеров и клиентов.

я собственно только об этом.

Цитата:

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

Чего, как мне кажется не хватает, это вожможномсти посмотреть все экстеншены с ключами и валидации.

Можно. Пусть делают. Пусть будет много внутренних инструментов. Да, я в курсе как это чудесно встроено во внутренний деплой, систему контроля и тестирования...
Но не стоит ожидать, что остальные будут впечатлены - они то не смогут этим пользоваться.

Цитата:

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

Дык фреймворк добавить проще чем менять компилятор. Я просто не вижу чтобы тут был какая-то большая проблема

Выше я приводил пример с советскими панельными домами. Вот собственно оно. Разработчикам проще добавить фреймворк. Остальное не учитывается.

Причем, belugin - образец вполне адекватного и взшенного подхода. Спасибо тебе, Макс.
Просто у него свои приоритеты. И не потому что он так решил, а потому что у него тоже есть начальство и тоже есть поставленные ему задачи и сроки.

Ключевой вопрос - что и как надо сделать, чтобы приоритеты у архитекторов-разработчиков внутри МС были хотя бы немного похожими на приоритеты потребителей (в данном случае разработчики партнеров и клиентов)...

Извините за дикий оффтопик.

[belugin]

Цитата:

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

Вызывать класс напрямую вообще говоря моветон в Аксапте (хоть МС делает это сплошь и рядом в стандартном функционале, сволочи)

что такое "вызывать класс"? info.add это вызывать класс или нет?

Цитата:

что делает МС, чтобы удовлетворить потребность людей?
никакого сахара для работы с инфраструктурой аксапты
минимализм и совершенно перпендикулярная остальной инфраструктуре технология атрибутов

Для этих классов это, насколько, я знаю не используется. Посмотри в коде аксапты где используется SysExtension Framework

Цитата:

Просто никто не думал о том, как ЭТО будут использовать конечные потребители - в данном случае разработчики партнеров и клиентов.

Я вообще не понимаю почему добавление атрибута на класс вместо того, чтобы добавить case куда-то внутрь метода вызывает какие-то проблемы? Единственное, что я вижу - это то, что просто сначала непривычно.

[mazzy]

Цитата:

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

что такое "вызывать класс"? info.add это вызывать класс или нет?

info.add - является.
запуск закрытия склада - является
запуск пересчета курсовой разницы - является
запуск отчета GER - является.
запуск из меню, из формы, как пакетное задание, в отдельном потоке и просто info.add - все это вызов класса. ты совершенно прав.

что из этого уже делается через SysExtensionAppClassFactory::getClassFromSysAttribute?
сколько нужно программировать чтобы вызвать классы при помощи SysExtensionAppClassFactory::getClassFromSysAttribute?

Цитата:

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

Для этих классов это, насколько, я знаю не используется. Посмотри в коде аксапты где используется SysExtension Framework

Вот именно! Нигде!! Му-ха-ха-ха!!!!

но это вовсе не означает, что людям не нужно этого делать. что у людей нет потребности. или нет сценариев такого использования.

это всего лишь означает, что предлагаемая технология очень ограничена.

Цитата:

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

Я вообще не понимаю почему добавление атрибута на класс вместо того, чтобы добавить case куда-то внутрь метода вызывает какие-то проблемы? Единственное, что я вижу - это то, что просто сначала непривычно.

Да-да.
Макс, ты не переживай. Не ты один не видишь, к сожалению. Просто ты работаешь не так, как работают на проектах. И потребности, и приоритеты у тебя другие.

[Bobkov]

Цитата:

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

Ключевой вопрос - что и как надо сделать, чтобы приоритеты у архитекторов-разработчиков внутри МС были хотя бы немного похожими на приоритеты потребителей (в данном случае разработчики партнеров и клиентов)...

Как бывший менеджер могу сказать, что наверное надо развить коммуникации между первыми и вторыми. Для этого нужны организационные формы, в рамках которых первые должны будут общаться со вторыми. Желательно чтобы это общение было постоянным и непосредственным. Тогда интересы вторых будут в значительной степени учтены.
В качестве простого наглядного примера, когда-то я как менеджер проекта добивался, чтобы члены проектной группы, которые должны общаться друг с другом, сидели не дальше двух метров друг от друга.

[skuull]

Цитата:

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

какая потребность есть у людей в Аксапте:
= изменить или добавить функционал, который могут использовать пользователи
== пользователи работают с функционалом через menuItem
== menuItem вызывает классы через статический метод main (menuItem также используются для вызова форм)
== права доступа к функционалу Аксапты настраивается через menuItem

Вызывать класс напрямую вообще говоря моветон в Аксапте (хоть МС делает это сплошь и рядом в стандартном функционале, сволочи)
Если вызывать напрямую, то нужно запрограммировать закат солнца вручную чтобы учесть настроенные права.
Функционал аксапты можно и должно вызывать через menuItem.

что делает МС, чтобы удовлетворить потребность людей?
никакого сахара для работы с инфраструктурой аксапты
минимализм и совершенно перпендикулярная остальной инфраструктуре технология атрибутов

Есть частные случаи когда МС о нас подумала (ну или так случайно вышло), вот конкретный пример.
Есть станадртный класс BankDepositSlip у которого нет наследников но он помечен

[Microsoft.Dynamics.AX.Platform.Extensibility.ExportInterfaceAttribute,
System.ComponentModel.Composition.ExportMetadataAttribute('BankCreateDepositSlip', 'BankDepositSlip'),
System.ComponentModel.Composition.ExportAttribute('Dynamics.AX.Application.BankDepositSlip')]

В main берется parm() из menuItem'а

public static void main(Args args)
    {
        BankDepositSlip instance;

        if (args && args.record())
        {
            instance = BankDepositSlip::construct(args.record(), args.parm());

            if (instance.prompt())
            {
                instance.runOperation();
            }
        }
    }

 protected static BankDepositSlip construct(LedgerJournalTrans _ledgerJournalTrans, str _variationName = 'BankDepositSlip')
    {
        BankDepositSlip instance;

        SysPluginMetadataCollection meta = new SysPluginMetadataCollection();
        meta.SetManagedValue('BankCreateDepositSlip', _variationName);
        instance = SysPluginFactory::Instance('Dynamics.AX.Application', classstr(BankDepositSlip), meta);
        
        Debug::assert(instance != null);

        instance.initInstance(_ledgerJournalTrans);

        return instance;
    }

И чтобы расширить это мне было достаточно
а) создать наследник пометив его другим атрибутом
б) создать новый menuItem с новым параметром.
Не все так плохо как хотелось бы

[mazzy]

Цитата:

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

В том что ты сделал: если задать сочетание Vend и MST это правильно что он молча это понимает и не ругается?

как я уже писал - этот проектик безумен настолько, насколько безумен исходный код, поставляемый майкрософтом.

да, можно передавать строковый тег.
но обычно стратегия определяется не menuItem, а datasource: если стоим на одной записи, то делаем одно, если на другой, то делаем другое, если вызываем из другой таблицы, то третье и так далее. а в менюИтемах задаются режимы обработки.

Цитата:

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

Если допустимо, чтобы он ругался на такое сочетание. То для расширения черех SysExt надо пометить атрибутом новый класс.

да. это было понятно.

собственно, как и раньше, имеем:
= эта штука работает на refleaction (со всеми вытекающими последствиями)
= вместо конструктора должен быть отдельный класс-запускач (дополнительно к адаптерам, хендлерам, хандлерам, хелперам добавляется еще и strategy)
= отдельный класс-запускач ломает систему перекрестных ссылок - теперь понять где что используется и как работает намного сложнее

да, в platform update 7 они таки сделали.

• new с параметрами
• атрибут помечается строкой с разделителем ";", а не enum
• в строке - позиционная запись параметров
• в строке никаких дефолтных значений
• в строке нет экранирующих символов чтобы экранировать ; в параметрах
• никакого синтаксического сахара
• строка похоже тупо проверяется на равенство - никаких регулярок, никаких критериев типа *?, никаких подстановок, никаких сравнений json-xml-структур.

Но:
= никакой параллельности или асинхронности в фреймворке не предполагается
= за уникальностью ключа должен следить сам программист
= ключ - строка, с позиционными значениями (почему не аксаптовский контейнер, не xml, не json, не другой сериализуемый объект? почему не использовать имя класса в качестве ключа?)
= вся стратегия определения ключа должна находится в одном месте - попытка сделать делегирование принятия решения о ключе приводит к возвращению к иерерхии конструкторов, только в отдельном классе.

Другими словами, все равно есть длинный список параметров с заданными позициями. но у них нет дефолтных значений. Та-дам!

А весь конструктор должен быть в одном методе. Со всеми пересечениями кода. Та-дам!

самое интересное, что эта штука не решает проблему подключения кода от разных производителей.
особенно, если разные производители добавлят классы с разными строками-ключами в середину иерархии. или добавят одинаковые ключи для разных классов.

Цитата:

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

Для того, чтобы сделать расширяемым надо сделать атрибут

мы все еще на уровне "надо сделать атрибут"?
да, все уже в курсе.
вопрос - какой? как? какова методика добавления класса в иерархию с атрибутами? как добавлять в середину иерахии? как добавлять класс листом в иерархию? кто следит за уникальностью? что должно произойти с методом, который вычисляет ключ после добваления новый классов в иерархию?

насколько эта байда проще-легче, чем просто код конструкторов?

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

Цитата:

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

Снести все фабричные методы заменив на вызов фреймворка

вот-вот! именно!

Цитата:

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

Можно завтра в обед попробовать вместе это сделать

можно. спасибо. только у нас щас должен быть engineering complete.
боюсь, что на этой неделе я только урывками во время компиляции.

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

Цитата:

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

вот конкретный пример.

спасибо.

Цитата:

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

И чтобы расширить это мне было достаточно
а) создать наследник пометив его другим атрибутом
б) создать новый menuItem с новым параметром.
Не все так плохо как хотелось бы

нет, конечно ))))))

подумайте еще.
для дальнейшего предметного обсуждения:
1. выберите пример с иерархическим семейством, а не плоским.
2. подумайте что будет, если в эту иерархию добавляет новые классы не один программист, а хотя бы два независимых программиста.
3. подумайте как предоставить эту расширенную функциональность пользователями.

и главное: а чем получившаяся конструкция по сути отличается от старых добрых конструкторов? (не считая дополнительной трудоемкости и отвалившихся перекрестных ссылок, конечно)

[EVGL]

Switch - это что, тоже технология? Вам нравится использовать эту технологию? Если нет, то почему?

Совершенно очевидно, для чего это было сделано. Все вклинивались в конструктор, теперь же этого делать не надо. Конечно, только там, где стандартный класс уже использует атрибуты. Где не использует - жалуйтесь разработчикам. Точно так же действуйте там, где необходим overlayering, а hook не предусмотрен - жалуйтесь. Может, сделают, скорее всего проигнорируют, но вы камень с души снимете, свою роль сыграете до конца.

И вообще, читайте первоисточники: http://patents.justia.com/patent/9026989.
Михаэль Галль и Михаель Понтоппидан зарегистрировали патент, завидуйте, придумывайте как сделать лучше и регистрируйте свои патенты.

[ax_mct]

Цитата:

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

И вообще, читайте первоисточники: http://patents.justia.com/patent/9026989.
Михаэль Галль и Михаель Понтоппидан зарегистрировали патент, завидуйте, придумывайте как сделать лучше и регистрируйте свои патенты.

US Patent for Object extensions using attributes to decouple base classes from derived classes Patent (Patent # 9,026,989)

Это же начала конца света. Война патентов на уровне написания кода.
Заслуживает отдельной темы разобраться. Звонок тревожный если ручки и до этого дотянулись. Прецендент. Ведь не придумали они это, а просто оформили.
P.S. Или это не стремление корпорации зарабатывать на способах написания кода, а инициатива авторов реализации чтобы наоборот тянуть с Microsoft??
P.P.S. Assignee - MS, значит владелец патента - Microsoft. Завидовать авторам - не хочется. Хочется их казнить

Patent History
Patent number: 9026989
Type: Grant
Filed: Jun 7, 2012
Date of Patent: May 5, 2015
Patent Publication Number: 20130332898
Assignee: Microsoft Technology Licensing LLC (Redmond, WA)
Inventors: Michael Gall (Copenhagen), Michael Fruergaard Pontoppidan (Lynge), Lars Dragheim Blaaberg (Karlslunde), Arthur Greef (Burien, WA)

[EVGL]

Цитата:

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

Это же начала конца света. Война патентов на уровне написания кода.
Заслуживает отдельной темы разобраться. Звонок тревожный если ручки и до этого дотянулись. Прецендент. Ведь не придумали они это, а просто оформили.
P.S. Или это не стремление корпорации зарабатывать на способах написания кода, а инициатива авторов реализации чтобы наоборот тянуть с Microsoft??
P.P.S. Assignee - MS, значит владелец патента - Microsoft. Завидовать авторам - не хочется. Хочется их казнить

То есть как? Михаэль Галль и придумал. Он еще много чего придумал, например Source Document и Subledger, вот, мучаемся, но с точки зрения пользователя/консультанта - классная вещь. Господин Белугин, наверное, много может на эту тему написать, ведь ему под это пришлось мою корреспонденцию переделывать, не так ли?

Корпорация Microsoft пополнила свой многотысячный багаж патентов, все правильно, рабочее время и интеллектуальный продукт принадлежит корпорации. Сами изобретатели повесили себе на грудь то есть LinkedIn, чтобы потом продать себя подороже.

В чем проблема?

[ax_mct]

Цитата:

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

В чем проблема?

Проблема в том что теперь нужно смотреть какой способ организации своего кода бесплатен, а какой нет. Я раньше вообще не подозревал что такие патенты существуют.

Создаю я скажем свой продукт или беру Open-source, продаю решение клиентам. А потом разоряюсь так как использовал способ написания кода который запатентован.
Или в этом продукте который я использую такое содержится. Это что же мне все патенты читать?

Причем разоряюсь еще до суда, так как почти уверен что мои профессиональные страховки на юридические услуги не учитывают нарушение авторских прав.

Сорри за оффтоп. Пока непонятно тема это или нет.

[belugin]

Цитата:

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

Господин Белугин, наверное, много может на эту тему написать, ведь ему под это пришлось мою корреспонденцию переделывать, не так ли?

Я бы сказал, что там есть две вещи - с точки зрения программиста-локализатора часть кода стновится ненужна - так как информация о создаваемых проводках вписана во фреймворк, то не надо ее дублировать при помощи vref2log и прочего. То есть корреспонденция корреспондирует все что реализована при помощи subledger - не надо отдельно прописывать корреспонденцию для FTI и для VendInvoice

Есть некоторые претензии к понятности того, что получилось, но они за счет

1) Больших методов в SubjedgerJournalizer
2) Быстродействия и нерасширяемости пакетных insert into (дублирование кода в extensions)
3) Нарушения принципа tell-don't-ask кое где.

Это никак не связано с тем, создавать ли классы при помощи Case или при помощи атрибутов.

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

[EVGL]

Исходный вопрос превратился в "как обойтись без overlayering". Да никак, ответ все тот же: "Option 3: Admit that your solution is not feasible in Dynamics 365 for Operations". Поскольку хотя указанный класс и использует форму, которую можно расширить, то сам класс и все методы работы с query объявлены как protected. Game over.

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

Но мы-то знаем, что на самом деле модуль проектов из маркетинговых соображений отложен на пыльную полку и практически не развивается с 2014 года, а модификаторы методов - это отнюдь не скрижали и не голос из неопалимой купины, а быстрая тяп-ляп работа под конец рабочего дня. С тем же успехом модификаторы можно было расставлять по броску костей, но вдруг 10 лет спустя после написания кода верховный жрец-разработчик узрел их тайный смысл и произнес роковые слова: "ТАБУ!"

[mazzy]

Цитата:

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

Да никак, ответ все тот же: "Option 3: Admit that your solution is not feasible in Dynamics 365 for Operations". Поскольку хотя указанный класс и использует форму, которую можно расширить, то сам класс и все методы работы с query объявлены как protected. Game over.

Ай-ай-яй... Плохая-плохая Аксапта.
Никак не подходит под патентованную технологию. Расст-елять! Неп-еменно расст-елять!
А патентованная технология замечательная. Да-да.

Ну, ничего, в данном случае можете снять мешающие вам final, protected
можете использовать другое семейство классов с несколькими уровнями.

Просто продемонстрируйте проектик с добавленной функциональностью, которую могут использовать пользователи со специальными правами,
в которой используется мощнейшая технология атрибутов и SysExtensionAppClassFactory::getClassFromSysAttribute.

Ведь это ж "просто пометить атрибутом".