Что значит несколько моделей? из вью точка входа в модель

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

так модель сама может состоять из нескольких классов

но точка входа из вью одна

я понимаю, но как модели шарят между собой одну инстанцию?

посмотри на RESUME в примере

не совсем понял как resume поможет в такой ситуации: у меня есть логика, состоящая из нескольких классов, например документ ссылается на договор, договор ссылается на партнера, партнер ссылается на ответственного и т.п. При сохранении документа я проверяю что все ок: все поля документа заполнены, договор действующий, партнер не заблокирован, отвественный не уволен. Потенциально 3 ответственности, 3 класса, каждый хочет че-то залогировать. Как это происходит. Каждый класс создает инстанцию лога, и возвращает ее потом или все они каким-то образом одну инстанцию шарят? Показать естественно я хочу все одновременно потом в самом конце

лог создается во вьюшке. в каждом классе в момент возникновения ошибки делаешь RAISE EXCEPTION (если дальшйшая работа невозможна) или RAISE RESUMABLE EXCEPTION (если можно продолжить сбор ошибок). В классах с бизнес логикой никаких логов и таблиц со сборщиками ошибок не нужно делать.

ну ок, это был мой первый вопрос по сути. Бизнес логика общается только эксепшенами, а у них есть противный недостаток - не умеют во много сообщений

делаешь свой класс с исключением и туда в атрибуты хоть таблицу передавай

а просто информацию как в лог писать с таким раскладом? edit: вопрос снят, посмотрел код

все верно. Но это уже два класса

Дмитрий намекает о том, что так делать не очень

Почему? Класс для сбора логов один, а классов исключений хоть миллион

Это подход к сбору ошибок. Если стоит задача просто собрать сообщения. Например, логировать какие-то действия. Можешь в атрибуте класса создать лог и писать туда данные откуда тебе удобно.

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

Ок, допустим стоит задача собрать все ошибки по множеству классов. Как ты будешь их передавать в единый лог?

У меня это singleton, который доступен всем. Можно сказать что это лог-сам-себе-контроллер. Я называю это аспектом

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

А если у тебя модель состоит из 3 подмоделей. И по каждой модели надо сохранять в разные подобъекты slg. И потом вывести общий лог

Иногда это необходимо, поэтому и придумали аспектно-ориентированное программирование. Лишние связи решаются скрытием за интерфейсом. Считай лог - это часть среды, как переменная sy. Тебе же не западло читать sy-uname каждый раз где хочется, а не передавать это значение через параметр

сильно не вчитывался в переписку выше. Мы для реализации несколько логово и подобъектов использовали мультитон и/или контролирующий класс. Инстанции логов получаются через класс-контроллер. Сохранение - тоже через него.

Тоже вариант, если ид лога определяется на этапе инстанциирования, у меня это просто параметры метода save)

Ну у вас получается глобальный супер класс со списком инстансов конкретных подобъекты лога.

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

Отдельно обрабатываются коммиты и ролбэки? Подробней плиз. Получается (грубо) супер класс с таблицей инстансов. Сами инистансы - это обёртка над фм bal* Александр предложил своё видение обёртки над фм bal*. У вас с Дмитрием Б. (я так понимаю вы с одной команды) придумана обёртка, чтобы рулить несколькими (или одной) обёртками.

с Dmitry B не знаком. Поэтому точно в разных командах работаем. В решении, которое сейчас используется у меня на проекте - есть класс менеджер. Он рулит логами. Логи могут быть как на базе баллога, так и другие - главное, чтобы они реализовывали z интерфейс. Над баллогом у нас также есть класс/классы, реализующие этот интерфейс. Теперь про коммиты-роллбэки - тут наша придумка. У нас управляющий класс реализует метод завязанный на событие cl_system_transaction_state - transaction_finished. Это событие возникает при явных коммитах и ролбэках. В нем мы принудительно сохраняем все дельты по логами (как баллоги, так и прочие). Таким образом даже при ролбэке наши логи сохранятся. Исключение - если лув не будет закрыт явно. Но это с этим мы справляемся, принудительно вызывая общее сохранение на верхних уровнях (например в методах dpc классов). А так как сохранение у нас происходит дельтами - лишняя информация не попадает в бд.

У меня по сути не обертка над BAL_*. Не видел смысла. Есть только методы-конвертеры read и save

READ и SAVE в BAL?

Про ролбэки и коммиты: т.е. я не смогу сам рулить процессом, когда сохранять лог в бд? Сохраняется автоматом при коммите. И можно подробней про дельты? Как высчитываете?

рулить сам можешь. У нас специфика проекта - все логи обязаны быть сохранены. А если что-то пойдет не так, чтобы было сохранено помаксимуму. Поэтому для надежности мы сохраняем логи не только при явном вызове метода save у класса-менеджера, но и при любом завершении лувов. Если вдруг возникнет потребность управлять необходимостью сохранения - это легко допилить, на этапе конструктора. А реализация дельт - зависит от лога. Флаги, индексы последнего сохраненного сообщения, получение актуалки - как угодно. В бал логах не помню как у нас. Возможно смотрим, что уже было сохранено ранее, и пишем новое.