Проблема: заказчик захотел крайне "жирную" смартформину. В итоге интерфейс (в табличной части) разрастается в геометрической прогрессии относительно его пожеланий.

Хочу узнать Ваше мнение: что лучше - использовать смартформу только для вывода заранее подготовленных данных, передаваемых через интерфейс, или просто передать ключ объекта, а все селекты сделать внутри ее?

Сейчас реализован первый вариант, но честно говоря вызов ФМ скоро на экран не поместится...

так а почему бы не сделать группу функций для чтения из DB и использовать функции внутри смартформы

То есть второй вариант?
Разницы нет - заворачивать всю дребедень в ФМ или просто в подпрограмму смартформы ИМХО. Только при вызове другого ФМ производительность будет еще ниже, чем просто селекты нарисовать.

разницы особой нет - выглядит эстетичнее - а о производительности - затратах на загрузку группы функций и т.д. - для вас это разве критично ?

Относительный вопрос, пока не очень, но...

В книжке SAP Press насчет Smart Forms озвучена примерно такая идея: если Output стандартный (инвойс, например), то интерфейс формы и программу не трогайте, а всякую дополнительную выборку данных делайте непосредственно в форме; если же форма полностью своя, то лучше выбирать данные в подпрограмме и передавать в форму. В последнем случае в форме уже никаких SELECT не будет, грубо говоря.

В плане производительности IMHO никакой разницы, т.к. "как ни ложись, все равно поимеют". Форма без дополнительных SELECT более универсальна, на мой взгляд, и может быть использована с разными программами. Хотя это не всегда требуется, так что может быть сомнительным преимуществом. Опять же IMHO - в отдельной программе код проще оптимизировать, отследить выполнение и проверить правильность выборки, а если код в самой форме, то ищи свищи.

Что касается вызова ФМ, так сделайте просто большую структуру наподобие LBBIL_INVOICE. Совершено не обязательно тонну разных таблиц передавать. Или я что-то недопоняла?

По-хорошему, модель (выборка данных) и вид (смартформа) должны быть максимально разделены.

Например, не так давно российский аддон перешёл со смартформ на pdf-формы (ну и другие формы тоже). Те формуляры, у которых развёрнутый интерфейс и никаких select'ов внутри, перенести в новую технологию проще. pdf-формы тоже поддерживают ABAP, но делается это через обратный вызов с ADS-сервера в сервер приложений SAP и выполняется очень медленно.

Лично я тоже за максимальное разделение бизнес-логики (ABAP) и представления (Smartforms). Если форма жирная и с кучей вариантов - реализуйте базовый класс и сделайте от него кучу потомков с переопределенными методами.

Эти потомки-дельты обычно помещаются на 1-2 экрана и легко отлаживаются.

Совать любую логику в смартформы я бы стал только в тех случаях, когда ГАРАНТИРОВАННО известно, что смартформа небольшая и модифицироваться не будет. Во всех остальных случаях к вам прибегут клиенты с фразой "а вот этому контрагенту надо нулевую цену печатать, а вот этому не надо битум выводить" и получится портянка с кучей вложенных IF и странными селектами в стиле "найди меня".

+1 за разление логики от формы

Я за разделение ABAP и Smartforms. Для продуктивности нет разницы, а
Smartforms. легче и гибче, да и в ABAP удобнее

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