Таблицу вставить в длинные тексты нельзя. То что предлагаете вы - это вставлять HTML код в сам текст. Но тогда SO10 нельзя использовать как WYSIWYG редактор. Это ограничение обесценивает использование текстов как шаблонов E-mail сообщений.
На мой взгляд использовать длинные тексты для шаблонов E-Mail крайне не удачная идея. В текстах нет возможности вставки таблицы, которые часто нужны в письмах.
У нас тестами покрываются библиотеки общего назначения и переиспользуемые классы. Писать тесты для отчётов зачастую более трудозатратно чем тест вручную, а автоматизация тестирования проводок или интеграций сложна в реализации или зачастую невозможна.
Добавлю что SET UPDATE TASK LOCAL не сработает, если ранее были зарегистрированы ФМ обновления в текущем LUW. Узнать это можно проверив SY-SUBRC.
Также следует помнить что изменения касаются только для модулей V1, модули V2 будут работать без изменений.
> В чем ещё плох подход application-а с конструктором? В том что у селекционного экрана куча событий, которые нужно обрабатывать в более менее серьезном отчете. У экранов обычных событий не так много, но все же они есть, и их тоже кто то должен обрабатывать.
Да, у селекционника может быть много событий. А в чем проблема?
1. Вы предлагаете модели подписываться на события вьювера? Тогда для чего нужен контроллер?
2. Локальные классы имеют доступ к глобальным переменным. Также GUI элементы необходимо будет создавать в основной программе что делает невозможным использовать их в других разработках. Если View наследовать от ALV, то View и Controller будут сильно сопряжены.
3. Если в конструктор передавать структуру с критериями, то такие разработки очень легко поддерживаются. Допустим, расширился экран выбора на несколько параметров. Потребуется расширить структуру CRITERIA и все. Остальная логика не будет затронута.
Данная архитектура проверена временем как на простых отчетах, так и на программах со сложной экранной логикой.
Архитектурные паттерны не следует применять во всех задачах подряд. Если у вас простой ALV отчет, то использовать данный подход не имеет смысла. А если есть экраны, подэкраны и дополнительный набор функций, то отсутствие архитектуры может свести к тому, что программа станет не поддерживаемой через некоторое время.
Что касается вашего комментария:
это может быть задача упростить дальнейшую поддержку и модернизацию
Да, это упростит дальнейшую поддержку и сделает программу более гибкой к расширению функционала
Я утверждаю, что при таком мотиве гораздо лучше использовать общепринятый подход, т.е. просто выделить в отдельные perform код для выборки данных, вывода ALV и реакции на user-command
Ваши утверждения не обоснованы. Вызов PERFORM означает использование процедурного программирование. Это не общепринятый подход, а практически единственно возможный способ программирования в ABAP до появления ООП.
Ваша же схема потребует от нового разработчика долго разбираться, какой же там мега-шаблон вы использовали и не дает никаких преимуществ для целей поддержки.
Напротив, поддержка будет более простой и гибкой если знать принцип. А для понимания принципа достаточно прикрепить ссылку на статью в задании на разработку ;)
Может быть другая задача — сделать больше одного пользовательского интерфейса
Я в качестве примера приводил когда требуется выводить данные в разных представлениях: ALV, Excel, PDF.
Таблицу вставить в длинные тексты нельзя. То что предлагаете вы - это вставлять HTML код в сам текст. Но тогда SO10 нельзя использовать как WYSIWYG редактор. Это ограничение обесценивает использование текстов как шаблонов E-mail сообщений.
Сложилось впечатление, что комментарий сгенерирован нейросетью.
На мой взгляд использовать длинные тексты для шаблонов E-Mail крайне не удачная идея. В текстах нет возможности вставки таблицы, которые часто нужны в письмах.
У нас тестами покрываются библиотеки общего назначения и переиспользуемые классы. Писать тесты для отчётов зачастую более трудозатратно чем тест вручную, а автоматизация тестирования проводок или интеграций сложна в реализации или зачастую невозможна.
Если добавить объект в настройку, то будут записываться новые тексты. А как вы записывали исторические тексты в эту таблицу?
В 740 данный класс отсутствует.
Также следует помнить что изменения касаются только для модулей V1, модули V2 будут работать без изменений.
Да, у селекционника может быть много событий. А в чем проблема?
2. Локальные классы имеют доступ к глобальным переменным. Также GUI элементы необходимо будет создавать в основной программе что делает невозможным использовать их в других разработках. Если View наследовать от ALV, то View и Controller будут сильно сопряжены.
3. Если в конструктор передавать структуру с критериями, то такие разработки очень легко поддерживаются. Допустим, расширился экран выбора на несколько параметров. Потребуется расширить структуру CRITERIA и все. Остальная логика не будет затронута.
Данная архитектура проверена временем как на простых отчетах, так и на программах со сложной экранной логикой.
Что касается вашего комментария:
Да, это упростит дальнейшую поддержку и сделает программу более гибкой к расширению функционала
Ваши утверждения не обоснованы. Вызов PERFORM означает использование процедурного программирование. Это не общепринятый подход, а практически единственно возможный способ программирования в ABAP до появления ООП.
Напротив, поддержка будет более простой и гибкой если знать принцип. А для понимания принципа достаточно прикрепить ссылку на статью в задании на разработку ;)
Я в качестве примера приводил когда требуется выводить данные в разных представлениях: ALV, Excel, PDF.