Эпиграф 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 - да, если писать правильно, то перекрестные ссылки есть