У меня доступ только в S/4, там все эти объекты идут с релизом 754, однако на просторах интернета и таблицы и классы помечены как созданные в рамках релиза 740.
Т.е. получается, что:
1. класс Application не полностью реализует функционал приложения, что, на мой взгляд, странно. Интересно, как вы будете строить архитектуру решения, если вам потребуется сделать alv grid на селекционном экране для выбора, например классов классификации, а в отчете будет еще два alv grid-а;
2. скорее всего, ни один такой отчет вы не используете дважды и каждый раз пишете много одинакового или однотипного кода, т.е. во времени разработки нет выигрыша;
Проблемы, может быть и нет. Просто интересно, как вы обрабатываете, например, события INITIALIZATION, AT SELECTION-SCREEN OUTPUT, AT SELECTION-SCREEN, если они будут зависеть от данных, введенных на селекционном экране. По идее, эти события должны обрабатываться классом приложения, но экземпляр этого класса вы создаете только в START-OF-SELECTION.
Напишу. Про break-point id много статей про то, как работать с ними в транзакции saab. Я попытался ответить на вопрос, как их использовать при разработках. Когда у меня возникали такие вопросы раньше, в интернете я ничего толком не нашел
Есть разные события у того же грида. Одни работают исключительно с данными, влияют на них и их обработку стоит делать в модели, а есть события, которым не нужен доступ к данным, их можно обрабатывать в контроллере. Вообще можно сказать, что cl_gui_alv_grid уже является контроллером.
Не так страшны глобальные переменные как использование их или их аналогов. В моих отчетах единственные глобальные переменные это параметры селекционного экрана, доступ к которым осуществляется внутри класса application, в других они практически ни к чему.
В чем ещё плох подход application-а с конструктором? В том что у селекционного экрана куча событий, которые нужно обрабатывать в более менее серьезном отчете. У экранов обычных событий не так много, но все же они есть, и их тоже кто то должен обрабатывать.
Создаётся впечатление, что вы заложник архитектуры и используете ее только ради использования архитектуры.
Согласен в том, что в abap сложно полноценно реализовать mvc, но такой вариант реализации MVA, на мой взгляд, сложен. Хотя иногда приходиться делать что то подобное. Полностью тут я вряд ли опишу свой подход, задам несколько вопросов:
1. Почему бы модель не сделать обработчиком событий view-ера? Так как у события есть sender, модель сможет влиять на view и получать данные о его состоянии.
2. Что плохого в локальных классах, если речь идёт о типовом отчете с селекционным экраном? У меня обычно три класса — application, model, view. Для приложения я использую интерфейс, viewer обычно наследует класс-обертку над cl_gui_alv_grid. Если вариантов представления несколько, есть класс для каждого view.
3. Я раньше тоже в каждом application делал конструктор с параметрами, это слишком долго и плохо поддерживается. Это ещё и мешает прийти к такой архитектуре, которую можно использовать повторно и получать выгоду в скорости
Думаю, что использование средств ООП в простых отчетах с alv оправданно с точки зрения сокращения времени разработки. Вы можете использовать интерфейсы для определения методов, которые обычно работают в отчете. А для alv-grid можно сделать удобную обертку. А если вы пишете подпрограммы вы неизбежно себя повторяете и тратите кучу времени в рутинных задачах
Сейчас уже точно не помню, но кажется мы создали простую программу, которая
выбрала все записи заголовков текстов из STXH для наших TDOBJECT;
считала их через READ_TEXT;
пересохранила их через SAVE_TEXT;
Судя по пакету S_ESH_CNT_SAPSCRIPT, это все таки функционал из Release 754, SP 1.
У меня доступ только в S/4, там все эти объекты идут с релизом 754, однако на просторах интернета и таблицы и классы помечены как созданные в рамках релиза 740.
1. класс Application не полностью реализует функционал приложения, что, на мой взгляд, странно. Интересно, как вы будете строить архитектуру решения, если вам потребуется сделать alv grid на селекционном экране для выбора, например классов классификации, а в отчете будет еще два alv grid-а;
2. скорее всего, ни один такой отчет вы не используете дважды и каждый раз пишете много одинакового или однотипного кода, т.е. во времени разработки нет выигрыша;
Напишу. Про break-point id много статей про то, как работать с ними в транзакции saab. Я попытался ответить на вопрос, как их использовать при разработках. Когда у меня возникали такие вопросы раньше, в интернете я ничего толком не нашел
Создаётся впечатление, что вы заложник архитектуры и используете ее только ради использования архитектуры.
1. Почему бы модель не сделать обработчиком событий view-ера? Так как у события есть sender, модель сможет влиять на view и получать данные о его состоянии.
2. Что плохого в локальных классах, если речь идёт о типовом отчете с селекционным экраном? У меня обычно три класса — application, model, view. Для приложения я использую интерфейс, viewer обычно наследует класс-обертку над cl_gui_alv_grid. Если вариантов представления несколько, есть класс для каждого view.
3. Я раньше тоже в каждом application делал конструктор с параметрами, это слишком долго и плохо поддерживается. Это ещё и мешает прийти к такой архитектуре, которую можно использовать повторно и получать выгоду в скорости
Верно, при фоновых задачах break-point id не работает. В фоновых и даже rfc- вызовах работает cl_debug. Про него можно написать целый отдельный пост. Правда, это уже сделано
https://consolut.com/supportportal/sap-online-help/sap-documentation/documentation-view/?article=n-cl_debug Тут на английском коротко
Тут по-русски подробно, но нужна регистрация https://sapland.ru/kb/articles/stats/novie-instrumenti-otladki-v-sisteme-sap-erp-prakticheskie-rekomendatsii.html
В принципе, я могу написать отдельно про cl_debug и отладку фоновых процессов, но чуть позже — сейчас пишу другой пост.