Итератор с поддержкой методов обратного вызова для обработки контролов на форме

[gl00mie]

Во вложении - вспомогательный класс для итератора, обновленный для использования в AX 2009.

PS. Для себя я сделал класс DEV_FormHelpers используемым в итераторе по умолчанию в тех случаях, когда в качестве метода обратного вызова указывается статический, а не экземплярный метод (т.е. _callbackObject == null):

public static client boolean DEV_iterateThroughFormControls(
    Object          _parentControl,
    Object          _callbackObject,
    identifiername  _callbackObjectMethodName,
    Set             _setOfClassIds2InvokeOn,
    boolean         _recursive                      = true,
    classId         _staticCallbackMethodClassId    = classnum(DEV_FormHelpers)
   )

[mazzy]

вопрос из другой ветки Как глобально отключить автоопределение ширины столбца = autoSizeColumns(false) ?

Цитата:

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

Оно бы хорошо, если б речь шла об однократном привешивании картонки к фанерной стене, однако ж, если верить перекрестным ссылкам, я лично этот итератор уже использовал в 16-и различных местах приложения.

а для каких задач может использоваться данный итератор?

[gl00mie]

Цитата:

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

а для каких задач может использоваться данный итератор?

Собственно, большинство решаемых задач описаны в этой ветке:

• какие-то универсальные вещи, наподобие кнопки "увеличить точность отображения" в настройке форм (SysSetupForm) или уже обсуждавшаяся рихтовка свойств grid'ов различных форм;
• мелкая рихтовка вида контролов, которые входят в группы с AutoDataGroup = Yes (очень уж мне нравится это свойство, неохота от него отказываться из-за ерунды);
• более затейливые сценарии, когда, к примеру, "нужно сделать форму, доступную только на чтение", при том что у потенциального пользователя есть доступ к ключам контроля доступа с уровнем выше, чем чтение - в этом случае при запуске формы с определенным параметром помимо установки свойств datasource'ов еще можно пробежаться по всем кнопкам и те, у которых NeededAccessLevel больше View (т.е. действия которых могут изменять данные на форме), - скрыть. Можно возразить, что надо такие вещи решать настройками прав доступа, но, пардон, UAC в виндах решает примерно те же задачи: хочешь - работай под администратором, имея полные права на все, но по умолчанию в действиях будешь ограничен. Конечно, такой подход требует корректного выставления NeededAccessLevel на пунктах меню, но при "традиционной" настройке прав доступа это требование не менее актуально.
• сценарии, когда одна форма каких-нить журналов используется для ндцати (в моем случае - 10-и) немного отличающихся типов журналов, при этом одни и те же поля журналов для тех или иных типов могут иметь несколько отличающийся смысл, и пользователи хотят видеть там разные метки. В этом случае классы-наследники базового класса управления формой могут переопределить метод, возвращающий "нестандартную" метку для того или иного поля в строках журнала, а базовый класс дергает итератор, проходится по всем контролам, связанным с datasource'ом строк журнала, вызывает этот метод, возвращающий новую метку и, если возвращенное значение метки для поля, к которому привязан контрол, не пустое, устанавливает для контрола новую метку.

В общем, я лично с помощью итератора решаю в основном те задачи, которые при "традиционном" подходе требовали бы работы с каждым из заранее известного множества контролов в каждой из заранее известного множества форм, при том что эти множества на момент разработки могут быть еще неизвестны. "Традиционный" подход в таких случаях требует, как правило, слишком большого объема ручной работы, отказа от использования "автогрупп" контролов на основе табличных групп полей, внесения избыточных модификаций в стандартные формы (как с теми же гридами в AX 2009), плюс ко всему он еще и удорожает сопровождение сделанных модификаций.

[mazzy]

Цитата:

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

[/LIST]В общем, я лично с помощью итератора решаю в основном те задачи, которые при "традиционном" подходе требовали бы работы с каждым из заранее известного множества контролов в каждой из заранее известного множества форм, при том что эти множества на момент разработки могут быть еще неизвестны. "Традиционный" подход в таких случаях требует, как правило, слишком большого объема ручной работы, отказа от использования "автогрупп" контролов на основе табличных групп полей, внесения избыточных модификаций в стандартные формы (как с теми же гридами в AX 2009), плюс ко всему он еще и удорожает сопровождение сделанных модификаций.

Но ведь при таком подходе SysSetupForm превращается в бутылочное горлышко, которое "знает" о деталях других форм. Т.е. в SysSetupForm будет некий большой switch, которые знает о деталях поведения других форм.

Это же противоречит объектно-ориентированному подходу и полностью нарушает инкапсюляцию.
Говоря в терминологии C++, ты создаешь класс, который является френдом очень многих других классов. Эдакий супер-френд. Со всеми вытекающими последствиями, которые вроде обсуждались у программистов С++. Например, чтобы выявить особенности поведения, тебе недостаточно понять как работает сам объект и его класс, тебе нужно понять как работают и все френды.

Разве не так?

[gl00mie]

Цитата:

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

Но ведь при таком подходе SysSetupForm превращается в бутылочное горлышко, которое "знает" о деталях других форм. Т.е. в SysSetupForm будет некий большой switch, которые знает о деталях поведения других форм.

А откуда взялось мнение, что всё вышеописанное реализуется в SysSetupForm? Там реализована только кнопка увеличения точности отображения, которая может быть применена к любой форме. Если же мне нужно переделать свойства пары контролов на форме, и я не хочу их для этого выдергивать из "автогруппы", то я просто дописываю метод на самой этой форме либо в классе управления этой формой, который при ее инициализации с помощью итератора меняет эти свойства. Пример такого метода приведен в самом первом сообщении данной темы (и в комментарии к нему ясно написано: "В коде на форме это выглядит примерно так").

PS. Сперва очень долго не мог понять, при чем тут вообще SysSetupForm - мне и в голову не могло прийти совать в него код, специфичный для особенностей дизайна какой-то одной конкретной формы.

[db]

Цитата:

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

А откуда взялось мнение, что всё вышеописанное реализуется в SysSetupForm? Там реализована только кнопка увеличения точности отображения, которая может быть применена к любой форме. Если же мне нужно переделать свойства пары контролов на форме, и я не хочу их для этого выдергивать из "автогруппы", то я просто дописываю метод на самой этой форме либо в классе управления этой формой, который при ее инициализации с помощью итератора меняет эти свойства.

Для всяких хитровывернутых фич вещь, в принципе, полезная.

Но пара контролов на форме это пушкой по воробьям. Чем element.design().controlName() то не угодил? Вроде прекрасно достает контролы из автогрупп. Или уже не достает и я отстал от жизни?

[mazzy]

Цитата:

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

А откуда взялось мнение, что всё вышеописанное реализуется в SysSetupForm?

А вот ни капельки такого мнения не было.
Реализуется метод в форме.
Но вызов то идет из SysSetupForm.
Это и есть friend.

Т.е. либо метод надо делать публичным, либо френдить SysSetupForm.
Поэтому SysSetupForm получается френдом для очень многих форм (другими словами, SysSetupForm слишком много знает о деталях реализации других форм), что приводит к снижению инкапсюляции.

(пусть в Аксапте нет ключевого слова friend. но смысл то и проблемы не меняются)

Цитата:

Если определяется класс, который не реализует математических объектов вроде матриц или комплексных чисел и не является типом низкого уровня наподобие связанного списка, то:
[а] Не используйте глобальных данных.
[b] Не используйте глобальных функций (не членов).
[c] Не используйте общих данных-членов.
[d] Не используйте функции friend (но только для того, чтобы избежать [а], [b] или [c]).
[e] Не обращайтесь к данным-членам другого объекта непосредственно.
[f] Не заводите в классе "поле типа"; используйте виртуальные функции.
[g] Используйте функции-подстановки только как средство значительной оптимизации.

...
Отметим, что общие базовые классы и друзья (friend) являются частью общего интерфейса класса (см. $$5.4.1 и $$12.4).

(C) Бьерн Страуструп. Язык программирования С++

[db]

Цитата:

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

А вот ни капельки такого мнения не было.
Реализуется метод в форме.
Но вызов то идет из SysSetupForm.
Это и есть friend.

Да нет там никаких таких вызовов (Функционал "расширения сознания" не в счет - он на своем месте). Все остальные специфичные для отдельных форм вещи реализуются прямо на этих отдельных формах