Цитата:
Сообщение от
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?"
Ребяты, прошу вас, не надо примеров "я создал пример из трех классов, я добавил атрибуты". такие примеры ничего не показывают.
Давайте рассматривать нормальный промышленный случай:
= есть семейство классов с несколькими уровнями иерархии
= есть несколько программистов
= которые добавляют/изменяют функционал этого семейства (одновременно или последовательно). в пределе это программисты разных партнеров, которые делают разные типовые решения. а некий программист заказчика ставит эти пересекающиеся типовые решения [из разных моделей]. (в целях упрощения, для данной ветки можно предположить, что модель одна, чтобы рассмотреть только механизм инстанцирования класса)
= как облегчить работу этих людей?
вы говорите ключи-атрибуты.
Ок, пусть.
Как должны выглядеть эти ключи, чтобы разные люди могли добавлять классы-потомки и не мешать друг-другу?
Как должны выглядеть эти ключи, чтобы в принципе была возможность рефакторинга? (да, я знаю что МС не рефакторит, но у партнеров и у заказчика то могут работать нормальные люди)
Зачем вообще нужны специальные ключи вместо имен классов?