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

[mazzy]

Эпиграф 1:
- Перебилдь
- Сам ты Перебилдь

Эпиграф 2:
Пока течет мой любимый кетчуп билдится мой любимый Retail...


для начала ссылка на прошлый проект с традиционными construct:

Цитата:

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

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

==============================
состав проекта:

==============================
Disclimer:
...

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

время на этом проекте конечно не показатель, поскольку сейчас много куда смотреть пришлось. но занимался я им 4-5 перебилдов и пару передеплоев ритейла - часа 4. следующие подобные проекты можно выполнять за те же 10-15 минут.

логика поведения Аксаптовских объектов вывернута наизнанку. Например, стандартно menuItem указывает на объект. А в фреймворке наоборот, к объекту привязывается menuItem, а в menuItem указыается клаcc запускач. И так во всем фреймворке.

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

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

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

и пока совершенно не понимаю, как ЭТО покрывать тестами.
и пока не могу найти примеров в существующем коде, чтобы ЭТО было покрыто тестами.
надо подумать.

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

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

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

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

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

===============================
ну, и строка-ключ с позиционными данными и с разделителем ;
это пипец, товарищи.

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