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

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

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

[mazzy]

Цитата:

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

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

Именно!
Внутри оно работает с именами классов. Ключ ТУПО преобразуется к именам. В текущей реализации Platform 7 ключ не имеет никакой семантики. Скрипач (отдельный ключ) не обязателен.

Цитата:

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

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

да-да. именно во множественном числе.

[belugin]

Цитата:

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

Именно!
Внутри оно работает с именами классов. Ключ ТУПО преобразуется к именам. В текущей реализации Platform 7 ключ не имеет никакой семантики. Скрипач (отдельный ключ) не обязателен.

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

Цитата:

да-да. именно во множественном числе.

Угу потому что выбранный тобой метод нужен в случае если требуется ровно один класс. Соответственно он требует у стратегии найти классы и если их больне одного то ругается. Если надо несколько, то getClassInstanceListFromSysAttribute

[mazzy]

Цитата:

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

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

Угу-угу.
и это не отменяет "Ключ ТУПО преобразуется к именам. В текущей реализации Platform 7 ключ не имеет никакой семантики."

Цитата:

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

Угу потому что выбранный тобой метод нужен в случае если требуется ровно один класс. Соответственно он требует у стратегии найти классы и если их больне одного то ругается. Если надо несколько, то getClassInstanceListFromSysAttribute

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

Макс, мы верим, что это работает.
Некоторые читатели даже знают как это работает.
А некоторые читатели даже давно используют.

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

Я говорил о том, что за уникальностью атрибутов фреймворк не следит - ответственность лежит на программисте (причем не на МС-программисте).
Я говорил о том, что в фреймворке далеко не везде идет работа с неуникальными атрибутами и классами - гораздо чаще фреймворк будет выкидывать исключение в runtime. И это тоже проблема программиста (причем не МС-программиста).

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

Я хочу донести мысль, что задачу "сделать классы read only" можно было решать разными способами. Но МС выбрал способ, который минимизирует трудозатраты только тех, кто создает новую функциональность. Полностью проигнорировав интересы остальных... Лично я очень хотел бы, чтобы учитывались интересы всех заинтересованных сторон.

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

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

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

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

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

[ax_mct]

Цитата:

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

...
Зачем вообще нужны специальные ключи вместо имен классов?

Каждый берет по вопросу. Чур это мой И я только мессенджер.

1. Ключ как внешнее имя
2. Можно менять в рантайме
3. Можно по условиям

By decoupling the base class from derived classes using instances of such attributes, a developer does not modify computer program code defining the base class when adding customized extensions to that base class.

The attributes can be specified at run time to specify or to alter the run time behavior of the application.
This framework also allows the application to conditionally instantiate an element based on its attributes.

Object extensions using attributes to decouple base classes from derived classes
http://patents.justia.com/patent/9026989

[mazzy]

Цитата:

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

2. Можно менять в рантайме

именно!
и статическая компиляция со статическим анализом превращается...

вот именно!

[belugin]

Цитата:

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

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

Проанализируй ключ в твоем примере - он составной - модуль и Node - можно их заменить именами классов?

Цитата:

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

У тебя есть класс с методом main, который все это знает. Я думал ты его имеешь ввиду. Я не создавал новых классов кроме атрибута. Есть класс-создаватель (фабрика) он готовый и я его не менял.

Цитата:

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

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

Цитата:

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

Не понял.

Цитата:

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

Я уже отвечал. Если нужны параметры конструктора, то используется следующий прием:

1. Во базовый класс добавляется метод init с нжными параметрами
2. Сразу после создания он вызывается.

Цитата:

выбери любой из них, который реализует несколько уровней иерархии.

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

Цитата:

Покажи как это просто.

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

Ok чуть попозже. Только учти что у тебя добавление элемента к существующему механизму создания объектов. А у меня будет еще и немного кода на перевод на новый механизм (как если бы ты перевел все на if вместо case )

Цитата:

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

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

Цитата:

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

Это я не понял.

Цитата:

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

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

Цитата:

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

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

Цитата:

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

Зачем ты его просишь тогда?

Цитата:

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

(Заметь что ты используешь разметку типа маркдауна внутри сообщения, но свою )

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

Цитата:

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

Я видел два способа. 1) GUID 2) Сесть на какой-то уже готовый способ распределения имен, например в java привязываются к домену комании (com.microsoft.dynsmics.forOperations) который распределяется в интернете.

Я предпочитаю привязываться к именам классов и таблиц.

Цитата:

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

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

Цитата:

Зачем вообще нужны специальные ключи вместо имен классов?

Чтобы создавать классы на основе бейзэнамов, например. В принципе, можно было бы обойтись одними классами, но MorphX не поддерживает автоматизацию создания UI для классов. Именно поэтому твой case не по классам а по base enum и строчке - в menuItem нельзя записать три параметра все из которых были бы классами.

Еще можно использовать сами классы в качестве ключей - посмотри SysClassNameAttribute

[mazzy]

Цитата:

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

Проанализируй ключ в твоем примере - он составной - модуль и Node - можно их заменить именами классов?

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

Цитата:

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

У тебя есть класс с методом main, который все это знает. Я думал ты его имеешь ввиду. Я не создавал новых классов кроме атрибута. Есть класс-создаватель (фабрика) он готовый и я его не менял.

в проекте на конструкторах не было main, который ВСЕ ЗНАЕТ. было main, которые знали о себе (как обычно)
в проекте на конструкторах не было contruct, который ВСЕ ЗНАЕТ. было два конструктора. каждый знает только о своем уровне и принимает решение своего уровня.

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

Цитата:

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

Тогда выбери любой другой пример.

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

Цитата:

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

Я уже отвечал. Если нужны параметры конструктора, то используется следующий прием:

Макс, ты снова рассказываешь "как это работает".
Я верю. Теперь я даже это видел своими глазами. "Прием" есть конечно.

Давай лучше поговорим о трудоемкости и об ответстенности за правильность результата.
Как бы ты оценил трудоемкость и удобность по сравнению со старым методом?
Мое мнение: Через жопу по сравнению со старым конструкторским методом.

Цитата:

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

Тебе нужна иерархия классов или иерархия ключей?
...атрибуты никак не должны эту иерархию отражать

Вооот!!!
И мы подошли к трудоемкости и удобствам.

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

Цитата:

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

Если первое, ... если второе, то ... правдя использована неколько раз там где надо делать классы ключами.

Именно!
Я посмотрел в существующий функционал насколько хватило терпения.
Пипец!!!

Цитата:

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

Ok чуть попозже. Только учти что у тебя добавление элемента к существующему механизму создания объектов. А у меня будет еще и немного кода на перевод на новый механизм (как если бы ты перевел все на if вместо case )

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

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

Но фиг с ним. Давай пока останемся в рамках задачи "добавление класса в иерархию"

Цитата:

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

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

Да, ортогональный
Да, никакой асинхронности.
Да, я совершенно зря загорелся надеждой...

Цитата:

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

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

"Также как и сейчас" - это ты очень хорошо сказал.
Если "также как и сейчас", то нафига огород городить?
А да, вспомнил, МС закрывает код базовых классов...

Цитата:

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

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

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

Цитата:

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

Зачем ты его просишь тогда?

и в самом деле!

Цитата:

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

(Заметь что ты используешь разметку типа маркдауна внутри сообщения, но свою )

Заметь, что в эту разметку никто не будет встраивать свои сообщения. На форуме при цитировании делается копия, старый текст и добавляется текст. И здесь нет компиляции )))

Цитата:

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

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

Макс... Я понимаю что ты хочешь сказать. Но просто сделай проектик (чуть более сложный чем одноувроенвое семейство из трех классов) И покажи в нем что хочешь сказать.

Цитата:

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

MS рефакторит. Несмотря на то, что при создании класса используется reflection это никак не мешает рефакторить

...майкрософту. пока билд не выпущен ))))
остальные не могут.
а тут еще и доступ к изменению исходного кода закроют.

Цитата:

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

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

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

Цитата:

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

Именно поэтому твой case не по классам а по base enum и строчке - в menuItem нельзя записать три параметра все из которых были бы классами.

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

Цитата:

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

Еще можно использовать сами классы в качестве ключей - посмотри SysClassNameAttribute

Да-да. У меня это был второй или третий вариант. В этом случае связь с классами автоматом, но зато связь с menuItem нужно делать руками.

Я старался сделать минимальный код при помощи штатных средств.

[belugin]

Цитата:

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

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

Заметь, что в исходном проекте использующем case делается специальное текстовое значение, которое повторяется в нескольких местах.

Цитата:

в проекте на конструкторах не было main, который ВСЕ ЗНАЕТ. было main, которые знали о себе (как обычно)
в проекте на конструкторах не было contruct, который ВСЕ ЗНАЕТ. было два конструктора. каждый знает только о своем уровне и принимает решение своего уровня.

Это ограничение, да, для каких-то сложных свопобов создания это не очень подходит. Но приведенный пример к ним не относится: родительский construct знает о существовании ключей, которые передает дальше.

Цитата:

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

В чем проблема с валидацией? Если ее надо делать до определения потомка, то вставить в вызывающий класс, если после, то в базовый.

Цитата:

Давай лучше поговорим о трудоемкости и об ответстенности за правильность результата.
Как бы ты оценил трудоемкость и удобность по сравнению со старым методом?
Мое мнение: Через жопу по сравнению со старым конструкторским методом.

Трудоемкость какого сценария? Добавление нового элемента - чуть меньше. Создание самой точки расширения - чуть больше или такая же.
Апгрейда при условии отсутствия breaking changes меньше.
Поиска зависимостей - примерно такая же.

Цитата:

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

Тут никакой иерархии атрибутов нет, атрибут ровно один.

Цитата:

Теперь программисту надо знать три вещи - иерархию классов, иерархию атрибутов и маппинг между ними.

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

Цитата:

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

В новом - меньше.

Цитата:

Да, ортогональный
Да, никакой асинхронности.
Да, я совершенно зря загорелся надеждой...

При чем тут вообще асинхронность и создание экземпляров классов.

Цитата:

"Также как и сейчас" - это ты очень хорошо сказал.
Если "также как и сейчас", то нафига огород городить?

Чтобы в других аспектах было не так же как и сейчас. Не все сразу.

Цитата:

Макс... Я понимаю что ты хочешь сказать. Но просто сделай проектик (чуть более сложный чем одноувроенвое семейство из трех классов) И покажи в нем что хочешь сказать.

Сконвертировал пример c case на жкстеншены. Не тестировал - мне кажется ты разобрался в концепции.