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

[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 куда-то внутрь метода вызывает какие-то проблемы? Единственное, что я вижу - это то, что просто сначала непривычно.

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

[belugin]

Цитата:

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

info.add - является.

"вызывать его напрямую вообще говоря моветон в Аксапте" ? Ты предлагаешь через menuItem?

Цитата:

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

Упс, тут я несколько перепутал. В 6 действительно почти нет вызовов такой штуки - весь Subledger сделан на такой же, но другой. А в 7 - SysPluginFactory.

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

Цитата:

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

И это правильно - у нее четкое предназначение.

Цитата:

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

Расскажи чем оно так сильно портит жизнь партнеру?

[mazzy]

Цитата:

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

"вызывать его напрямую вообще говоря моветон в Аксапте" ? Ты предлагаешь через menuItem?

я предлагал? покажи мне это место, пожалуйста.

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

Цитата:

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

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

Прекрасно. Только мы говорили про вызывать. Ты довел мысль только до расширения.
доведи свою мысль до вызова функцонала класса, пожалуйста.

можно на примере расширить периодическое сопоставление по клиентам, например. Некоторым пользователям можно запускать специальное сопоставление по клиентам. со специальными полями в диалоге, которые устанавливает специальное условия в query. Остальные поля - стандартные.

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

для определенности, давай сформулирую условие на старо-программистком:
= создать класс-потомок от CustVendAutoSettlement_Cust_RU (см. скриншот)
= ovverride метод dialog*
= ovverride метод query
= новый функционал должен работать как в пакетном задании, так и при непосредственном запуске пользователем
= новый функционал должен быть доступен только некоторым пользователям (желательно, чтобы система доступа была построена на стандартных правах аксапты)

=============
говоришь, кто-то указал, что это final класс?
ничего-ничего, на проекте можно [было] убрать это слово.
давай будем считать, что этого слова там нет.
=============

Цитата:

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

И это правильно - у нее четкое предназначение.

И какое же на твой взгляд?
А какое предназначение было у конструкторов, которых не будет?

Цитата:

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

Расскажи чем оно так сильно портит жизнь партнеру?

Макс, легко.
Обещаю, я сделаю это, после того, как ты покажешь как решить типовую задачу на типовом внедрении - как предоставить пользователю возможность запуска расширенного функционала тривиального семейства из 7-8 классов "просто пометив атрибутом".

[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. подумайте как предоставить эту расширенную функциональность пользователями.

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

[Logger]

Цитата:

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

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

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

[mazzy]

Цитата:

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

а почему бы не починить сбор перекрестных ссылок...

можно. можно много было чего сделать.
если всего-лишь начать думать о том, как "это" будут использовать люди.

ответ получен:

Цитата:

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

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

[mazzy]

Да, спасибо. Думаю, что остальным тоже будет интересно:

Цитата:

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

почему не использовать имя класса в качестве ключа?

Ответ глубоко в недрах фреймворка:


Да, похоже изначально в качестве ключа предполагалось просто имя класса.
Да, поддерживаются N-элементов. Пока реализовано для случая N=1.

[belugin]

Цитата:

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

Да, спасибо. Думаю, что остальным тоже будет интересно:


Ответ глубоко в недрах фреймворка:


Да, похоже изначально в качестве ключа предполагалось просто имя класса.
Да, поддерживаются N-элементов. Пока реализовано для случая N=1.

_baseCLassName это имя базового класса или интерфейса

 /// <summary>
    /// Searches for extensions for elements.
    /// </summary>
    /// <returns>
    /// The search result that contains elements that match the search attribute instance[.
    /// </returns>
    public SysExtensionCacheValue search()

То есть это не ключ а найденные классы

[belugin]

Цитата:

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

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

Ты сам выбрал этот пример. Можно и datasource - какая разница какого типа ключ - можно сделать и имя таблицы и ID.

Цитата:

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

Не нужно. Класс запускач и так у тебя был мы перерабатываем только создание.
Stragegy не обязательно. У тебя нет параметров в конструкторе (не путать с методом construct). Если параметры есть, достаточно добавить метод init(параметры).

Цитата:

= отдельный класс-запускач ломает систему перекрестных ссылок - теперь понять где что используется и как работает намного сложнее

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

Цитата:

Но:
= никакой параллельности или асинхронности в фреймворке не предполагается

Зачем она там?

Цитата:

= за уникальностью ключа должен следить сам программист

Так же как и в case - в 7 добавили проверку, но не для intrinsic finctions.

Цитата:

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

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

Цитата:

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

Для других паттернов - тругие решения, которые тут приводили - например экстеншены для конструкторов.

Цитата:

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

Это не параметры это ключ.

Цитата:

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

Нет конструктор находится в каждом классе (не путать с методом construct). Что такое пересечения кода, я не знаю.

Цитата:

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

Это решается так же как и любое пересечение имен в Ax - префиксами.

Цитата:

вопрос - какой? как? какова методика добавления класса в иерархию с атрибутами?

Я ж тебе пример привел.

Цитата:

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

4. Подумайте какие из перечисленных проблем новые для норвого механизма, а какие были и с кейзом.

Цитата:

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

Перекрестные ссылки не отвалились, надо просто смотреть другие ссылики

[mazzy]

Цитата:

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

Ты сам выбрал этот пример.

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

да, примером можно продолжать пользоваться.

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

Цитата:

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

Можно и datasource - какая разница какого типа ключ - можно сделать и имя таблицы и ID.

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

Цитата:

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

Класс запускач и так у тебя был

Снова приношу свои извинения за безумную реализацию от МС.
Нет, у меня не нужен класс запускач. Достаточно menuItem, который подцепляется к главному меню или к формам.

класс запускач нужен только для запуска класса из Visual Studio.
MenuItem можно сделать стартовым объектом в VS. Но в этом месте бага - параметры menuItem при старте из VS не учитываются. Сотрудники МС не используют этот сценарий ))))

Цитата:

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

мы перерабатываем только создание.

Да.

Цитата:

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

Stragegy не обязательно.

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

В фреймворке один стратегия должна знать обо всех классах иерархии.

Цитата:

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

У тебя нет параметров в конструкторе (не путать с методом construct). Если параметры есть, достаточно добавить метод init(параметры).

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

Цитата:

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

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

Макс, му-ха-ха (2 раза)
Сейчас в аск7 82 класса-потомка от SysExtensionIAttribute
выбери любой из них, который реализует несколько уровней иерархии.
Покажи как это просто.

Ты говоришь "просто добавить атрибуты".
Ты говоришь "просто смотреть"
Сделай проектик. Покажи как это просто.

вот на конструкторах по старому я сделал минут за 15 со скриншотами и написанием поста. Раз это так просто, наверняка займет меньше времени.

Цитата:

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

Зачем она там?

И в самом деле! Чего это я? Видать Котлинов всяких наелся...

Цитата:

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

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

Я смотрю актуальную аксапту. 7.2.1785.0
Да-да. Я вижу это "что угодно". Строка с ; Это пипец и детский сад какой-то.

Цитата:

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

Для других паттернов - тругие решения, которые тут приводили - например экстеншены для конструкторов.

Угу-угу. Именно! Другие.

Цитата:

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

Это не параметры это ключ.

Да. Согласен. Составной ключ. Содержит некие абстрактные параметры.

Цитата:

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

Нет конструктор находится в каждом классе (не путать с методом construct). Что такое пересечения кода, я не знаю.

Именно.

Цитата:

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

Это решается так же как и любое пересечение имен в Ax - префиксами.

Кем и как? Бгггг!!

Цитата:

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

Я ж тебе пример привел.

Макс, другие доказывающие - можно проектик?

Цитата:

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

4. Подумайте какие из перечисленных проблем новые для норвого механизма, а какие были и с кейзом.

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

Цитата:

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

Перекрестные ссылки не отвалились, надо просто смотреть другие ссылики

Именно.


Ребяты, такое ощущение, что вы продолжаете доказывать что фреймворк работает в принципе. Да все читающие эту ветку верят что работает. Если вспомнить, исходный вопрос ветки был: "Какая цель создания экземпляров классов через расширенные атрибуты? Чем не устраивает старый дедовский способ construct?"

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

Давайте рассматривать нормальный промышленный случай:
= есть семейство классов с несколькими уровнями иерархии
= есть несколько программистов
= которые добавляют/изменяют функционал этого семейства (одновременно или последовательно). в пределе это программисты разных партнеров, которые делают разные типовые решения. а некий программист заказчика ставит эти пересекающиеся типовые решения [из разных моделей]. (в целях упрощения, для данной ветки можно предположить, что модель одна, чтобы рассмотреть только механизм инстанцирования класса)
= как облегчить работу этих людей?

вы говорите ключи-атрибуты.
Ок, пусть.

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