Переопределение методов у FormDataSource созданного в классе

[Владимир Максимов]

Ребята, может, мы все-таки сначала послушаем "начальника транспортного цеха"? В смысле, автора темы.

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

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

[alexkrut]

Про задачу.

На работе автоматизируем один из отделов предприятия. Отдел занимается документами. Документы эти на 70-80 процентов похожи. Формы уже есть. Создавались в AOT. В формах соответственно 70-80 процентов повторяющегося кода. Если кто-то вдруг не понимает зачем нужно избавляться от повторения кода - книжка по рефакторингу вам в помощь.

Про ответы.

Цитата:

Сообщение от Владимир Максимов

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

А никто и не предлагал считать форму классом. Нужен класс, который рисует форму. И наследование уже от него, а не от созданной им формы.

Цитата:

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

2. Все методы датасорса формы, можно перекрыть на самой таблице (например, write, update, insert, delete, validateWrite, validateDelete, изменения по полям можно отлавливать в методе modifiedField()). И уже на таблице выполнять какие либо бизнес требования. Если эти требования специфичны для Вашей форме, добавьте параметр на входе.

Далеко не все. Нам нужен полноценный датасорс, у которого перекрыты нужные нам методы.

Цитата:

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

Используйте одну форму и семейство классов для управления ею, посмотрите, как работают формы шапок журналов, посмотрите, как работает форма итогов по закупкам в 2009-й (там датасорс в дизайне формы - по таблице Common).

Спасибо, ваши ответы пока самые вменяемые здесь!

[lev]

Цитата:

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

Далеко не все. Нам нужен полноценный датасорс, у которого перекрыты нужные нам методы.

Я имел ввиду все методы работающие с данными. Методы отвечающие за работу DataSource на форме (active(), reread(), refresh() и т.д. и т.п.) понятное дело перекрываются только у DataSource на форме.

Цитата:

Про задачу.

На работе автоматизируем один из отделов предприятия. Отдел занимается документами. Документы эти на 70-80 процентов похожи. Формы уже есть. Создавались в AOT. В формах соответственно 70-80 процентов повторяющегося кода. Если кто-то вдруг не понимает зачем нужно избавляться от повторения кода - книжка по рефакторингу вам в помощь.

Думаю для примера можно посмотреть как реализованы формы и их отображение у складских журналов (InventJournalTable): перенос, проводка, прибыль\убыток. Там тоже формы по каждому типу журнала на 70-80% одинаковы, но есть нюансы, которые разруливаются через семейство классов JournalFormTable (а точнее его наследник InventJournalFormTable) - это шапка журнала, и семейство классов JournalFormTrans (а точнее его наследник InventJournalFormTrans, у него тоже есть наследники, но думаю разберетесь) - это строки журналов.