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

[alexkrut]

Есть класс, который создает форму, добавляет контролы, создает и прикручивает к ним датасорс. Как у этого датасорса переопределить методы active(), init() и т. д. ?

[Мартынов Дмитрий]

Такого инструмента нет.
Возможно, если создавать программно форму в дереве АОТ, то это может получиться...

[alexkrut]

Подобный функционал есть для контролов, должен скорее всего быть и для датасорсов. Вообще проблему можно было решить наследованием от FormDataSource и переопределением методов там, но такое наследование запрещено разработчиками axapta: (

[pedrozzz]

Быть может проблему проще решить, накидав форму в АОТ. А контролы скрывать или показывать в зависимости от условий. Это как-то более "по-аксаптовски"...

[lev]

Цитата:

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

Есть класс, который создает форму, добавляет контролы, создает и прикручивает к ним датасорс. Как у этого датасорса переопределить методы active(), init() и т. д. ?

какая версия аксапты?

Посмотрел в AX2009 RU5 у класса FormDataSourse есть и метод active() и метод init() и пр.

static void Job27(Args _args)
{
    FormDataSource  fds;
    ;

    fds.active();
    fds.init();

    fds.validateWrite();
    fds.write();

    fds.validateDelete();
    fds.delete();
}

[alexkrut]

Использовать АОТ не хотелось бы, потому что форм много, и они примерно одинаковые. Слишком много кода приходится копипастить из формы в форму, изменения минимальны. Да и best practices опять же.

[alexkrut]

Цитата:

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

Посмотрел в AX2009 RU5 у класса FormDataSourse есть и метод active() и метод init() и пр.

Вам слово переопределить говорит о чем - нибудь? Мне не не нужны методы в чистом виде, мне нужно дописать туда свой код до и после super();.

[gl00mie]

Цитата:

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

Использовать АОТ не хотелось бы, потому что форм много, и они примерно одинаковые. Слишком много кода приходится копипастить из формы в форму, изменения минимальны. Да и best practices опять же.

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

[lev]

Цитата:

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

Вам слово переопределить говорит о чем - нибудь? Мне не не нужны методы в чистом виде, мне нужно дописать туда свой код до и после super();.

ага, не сразу заметил слово "переопределить" в Вашем первом сообщении, простите великодушно

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

Вообще конечно какой то немного извращенный способ создания формы. Может вы опишите какую цель преследуете? Возможно её можно решить как то иначе (проще).

[lvan]

Цитата:

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

Есть класс, который создает форму, добавляет контролы, создает и прикручивает к ним датасорс. Как у этого датасорса переопределить методы active(), init() и т. д. ?

никак

[shogel]

В AX2012 можно унаследоваться от FormObjectSetNotify, перекрыть методы onActive/onRefresh и после создания датасорса:

formDS.addNotifyHandler(this);

Насчет AX2009 не уверен.

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

Цитата:

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

Да и best practices опять же.

Вы не могли бы дать ссылку на соответствующую статью best practices, которая призывает создавать форым из класса? Ну, или на ту статью, которая показалась Вам соответствующей данному случаю?

А вообще-то, присоединяюсь к вопросу lev. Может, Вы все-таки опишите саму задачу, а не выбранный Вами способ ее решения? Просто подобный способ решения противоречит стандартной идеологии Axapta.

[gl00mie]

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

[Pustik]

Может быть, человек столкнулся с тем, что кто-то до него, на этом месте работы строил формы программно. Написано куча кода. И сейчас просят "кое-что отшлифовать". И без указанных выше переопределения методов в решении задачи не обойтись.Что делать? Переписывать все с нуля? Объяснить заказчику, что это фактически перекодирование проекта, которое займет уйму времени? Если так, то ситуация не самая приятная.

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

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

Понятно, что ситуации бывают разные. Однако очевидно, что в 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, у него тоже есть наследники, но думаю разберетесь) - это строки журналов.