FormTreeControl, Tree наследование. АХ2009

[YoungPadawan]

Здравствуйте!
Есть форма с деревом(Tree). Функционал работы дерева написан в методах дерева (на дизайне).
Хочу убрать код с дизайна.
Первое что приходит в голову: создать новый класс, передать в него контрол дерева, написать свои методы что бы соответствовать интерфейсу класса FormTreeControl и вызывать эти методы на том же дизайне в методах объекта Tree.
Этот вариант рабочий, но меня смущает то что нужно будет все равно перекрывать методы Tree и писать в них вызов своих.

И, как я думал, это решается наследованием.

Была идея создать наследника от FormTreeControl и добавить его на форму в коде.
Или в методе new объекта Tree написать такое this = new МойНаследник, но не смог проверить работает ли вообще такая конструкция, потому что класс FormTreeControl имеет модификатор final. И все мои надежды на "красивый" код рухнули.

Так вот, всем кто дочитал, есть ли какие-то варианты избавиться от какого-либо кода на дизайне?

[Ivanhoe]

Стандартные формы изучали?

[YoungPadawan]

Цитата:

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

Стандартные формы изучали?

Изучал.
В туториал - весь код в design ->Tree и в Element.

В правах групп пользователей - то что я описал в первом сообщении сообщении (методы класса вызываются в перекрытых методах на дизайне).

[SRF]

Я думаю фраза про стандартные формы подразумевала не только tutorial*, но в том числе и формы, в которых используется также контрол tree. К сожалению, доступа к ax2009 у меня нет сейчас, но в DAX2012 то, что вы хотите сделать, реализовано в формах RTax25ProfitTable, DimensionDefaultingLookup(этой формы в dax2009 нет, лукап форма фин. аналитик).

У себя поискать примеры вы всегда можете по перекрестным ссылкам, думаю найдете.

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

Цитата:

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

Здравствуйте!
Есть форма с деревом(Tree). Функционал работы дерева написан в методах дерева (на дизайне).
Хочу убрать код с дизайна.
Первое что приходит в голову: создать новый класс, передать в него контрол дерева, написать свои методы что бы соответствовать интерфейсу класса FormTreeControl и вызывать эти методы на том же дизайне в методах объекта Tree.

Это Best Practices в среде Axapta. Именно так все и делается.

Более того, у многих форм есть связанный с этой формой "обслуживающий" класс, который инициализируется в init-формы и методы этого класса вызываются из методов объектов формы. Именно с целью убрать код из методов формы в класс, который позже может стать классом-родителем

В Ax2012 факт наличия обслуживающего форму класса вообще стало не явным стандартом по причине изменений в дизайне и структуре данных.

Цитата:

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

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

Так вот Axapta устроена. С этим ничего не поделаешь...

Цитата:

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

И, как я думал, это решается наследованием.

Была идея создать наследника от FormTreeControl и добавить его на форму в коде.
Или в методе new объекта Tree написать такое this = new МойНаследник, но не смог проверить работает ли вообще такая конструкция, потому что класс FormTreeControl имеет модификатор final. И все мои надежды на "красивый" код рухнули.

"Это не наш метод" (с)

В среде Axapta классы визуальных объектов "неприкосновенны". Не перекрываются. А программное создание объектов на форме - моветон. Хотя, конечно, и так тоже делают...

Цитата:

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

Так вот, всем кто дочитал, есть ли какие-то варианты избавиться от какого-либо кода на дизайне?

Стандарт для Axapta

Форма - только отображает, а весь код - в связанном с этой формой классе. Вызов методов класса явным образом из соответствующих методов формы

Т.е. совсем ничего не писать в методах формы - не получится Но можно свести весь код к командам вызова соответствующих методов

[TasmanianDevil]

Цитата:

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

Но можно свести весь код к командам вызова соответствующих методов

Можно вообще свести все только к объявлению экземпляра обработчика в classDeclaration, его инициализации в init() формы (привязка к контролу дерева, форме и управляемому источнику данных на форме) и вызов отрисовки корня и первого уровня в run() формы. Все остальное - перехват и отработка классом-обработчиком событий контрола. Управление источником данных (создание/редактирование/удаление) - через контекстное меню дерева или перехват комбинаций клавиш на дереве, что тоже реализуемо в классе-обработчике. При должном уровне абстракции в реализации класса (работа через SysDict-семейство классов, Common и коды полей/таблиц) можно одним классом покрыть все деревья.

Мы у себя именно так и реализовали, дабы не повторять одно и то же по 17 иерархическим таблицам в 34 формах (на каждую по форме редактирования и lookup-форме).

[YoungPadawan]

Спасибо за Ваши ответы)

[Raven Melancholic]

Чтобы уж совсем все с нуля не писать, посмотрите класс CcFormTreeDatasource и его наследников - где и как используются.