солидарен, я тоже думаю, что проблемы с рефрешем связаны с моими попытками выводить гриды динамически, но к сожалению не всегда получается качественно(

у вас есть опыт реализации динамики в САПЕ? в конторе, где я работаю, на каждый грид принято писать 3 класса т.н. M-V-C патерн, но меня это удручает... слишком много классов получается, 2\3 от которых выполняют по сути одни и теже действия, поэтому я стараюсь выводить гриды динамически используя филд-символы и разыменованные переменные

1) наверное, подход, который диктуют вам в конторе, был не просто так выбран в качестве способа разработки.
2) Опыт разработки с использованием динамики у меня есть. В первую очередь он мне говорит: 10 раз подумать прежде чем его использовать, чтобы не спутать, где его надо юзать, а где - нет. Так что, мой опыт в этой части - вам не поможет

я в институте на с++, в основном кодил
там препод за подобный подход(3 класса на каждый чих) отправил бы на комиссию сразу(

т.е. вы рекомендуете не заморачиваться? в сапе эти трюки не важнецки реализованы

так вам же Кодер уже указал на ошибку. Вот эта строка ошибочная:

Вы каждый раз при изменении данных предварительно пересоздаете объект, а надо один раз создать скажем при инициализации (перед первым отображением ALV), а дальше уже просто обновлять в нем данные .

Данный объект должен быть аттрибутом view.

с этим уже всё ясно

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

Смотря в каких случаях и для каких задач.

в этой теме viewtopic.php?f=13&t=93009 я привёл пример, где я реализовал эту идею и это работало
можете что-нибудь рассказать\посоветовать по этому поводу? очень уж мне не нравиться по три класса на каждый чих писать

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

То, что с таким подходом не согласился бы преподаватель из вашего вуза, - это вполне нормально. Реальная промышленная разработка далека от ученических проектов.

Я не настолько прокачан, чтобы что-то конкретное посоветовать насчет задачи "На экране три вкладки с подэкранами" или "В ПБО экрана в зависимости от выбранных параметров присваиваются соответствующие параметры конструктора Представления." . В соседней теме (viewtopic.php?f=13&t=93259&p=554479#p554479) более развернутое описание, видимо, этой же задачи.
Имхо, полноценный MVC имеет смысл применять, если стоит задача (или есть перспектива) иметь возможность раздельно менять действия над данными и отображение данных. В рамках лично моего опыта получается, что каждый раз при попытке задействовать MVC данные связаны с действиями, поэтому у меня получалось ограничиться Document-View (или чем-то отдаленно напоминающим его ). Возможно, это особенности задач, возможно - особенности моего мышления.

вот с чем лично я столкнулся: транзакция подписания доков содержит более 100 классов. из которые 2\3 это V&C т.е. классы представлений и контроллеров.
получается что для того чтобы выводить несколько табличек(пусть даже много штук 10, но не одновременно) и по клику на кнопке поменять запись в БД и цвет строчки в этой таблице надо более 100 классов...
меня это смущает и очень сильно(

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

а тут более ста практически не о чём

есть ли способ на абапе писать более корректный код? более расширяемый без существенных переделок?

Вы действительно не понимаете или это уже такой толстый троллинг, что даже тонко? Эти моменты вам следует выяснять в своей проектной команде, а не на форуме. Архитектура проектного решения - это работа команды. Почему они так сделали и как вам сделать вашу задачу, вы должны узнать у них. А то складывается впечатление, что у вас там как в анекдоте "дали пистолет и крутись как хочешь".


Я искренне рад, что у вас была сложная и интересная магистерская работа. Но скажите мне: ваша программа внедрена на производстве? Сколько пользователей\единиц оборудования используют вашу программу? Сколько времени она уже работает? Как осуществляется ее поддержка. когда вы уже не с ней, а переключились на абап?
Если цель моих вопросов вам не понятна, то я сразу же и поясняю: в том числе и такие вопросы приходится учитывать при проектировании архитектуры

К сожалению, пока по вашим вопросам видно, что вы, не разобравшись до конца собственно в языке, его нюансах, а так же решениях вашей проектной команды, пытаетесь реализовать что-то свое.

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





Увы, кроме как в стенде в универе нигде(

К сожалению, пока по вашим вопросам видно, что вы, не разобравшись до конца собственно в языке, его нюансах, а так же решениях вашей проектной команды, пытаетесь реализовать что-то свое.
Отчасти. так и есть я только разбираюсь, как реализованы в АБАП классические ООПшные фишки. Именно поэтому и пишу на форуме, пытаюсь узнавать, что думают люди, читать курсы, топики... развиваться

Все это уже глубокий оффтоп.
AL13SH: Ну как видите, минимум один паттерн у вас применяют - MVC (про него даже GoF писали)
Для начала стоит просто заняться собственным ликбезом как в части абап, так и в части проекта и его регламентов.
Какие-то проектные решения могут быть продиктованы в том числе и удобством сопровождения решения. Я могу говорить только общими словами, т.к. подробности проекта можно узнать только у ваших коллег
"Гадать по фотографии" в вашем вопросе бесполезно. Форум все-таки место для разрешения конкретных технических вопросов (в свою очередь, могу вам посоветовать, очень четко их формулировать и предоставлять подробную информацию).

Благодарю за науку! учту

Добавлю свои 5 коп.

В большинстве случаев задача, изначально казавшаяся простой и не требующая сложной архитектуры, со временем усложняется и расширяется. Даже если не вами, то впоследствии поддержкой. Поэтому имеет смысл всегда закладывать её масштабируемость.

У SAP-а есть одно из достоинств - поиск использования объекта разработки в других объектах. Что сильно облегчает анализ кода и его дальнейшую поддержку другими разработчиками. Но это работает только для статичных объявлений, а для динамических объектов резко ухудшается "читабельность". Поэтому динамические объекты имеет смысл использовать там, где это оправдано, например, создаётся реально динамический отчёт - т.е. пользователь на селекционном экране определяет источник (таблицу) и состав (поля) отчёта.
В Вашем случае, возможно, имеет смысл 2-х уровневый динамически-статический подход. Например, от динамического класса, в котором реализуются универсальные методы обработки, создавать потомков со статичными параметрами методов, которые (методы) уже и будут использоваться во внешних вызовах.