Углублюсь в презентационные вопросы.

Какую структуру/идеологию/паттерны СЛОЖНЫХ пользовательских форм можно сконфигурировать вашим фреймворком ? Гриды/таблицы это более чем грустно и годится только для учебного примера. Реальная информация сложна, многолика. Ее качественное отображение на экране непросто продумать и придумать. Может ваш фреймворк сконфигурировать пользовательскую форму, одновременно содержащую зоны табличных представлений - гридов, структур/деревьев, табстрипов, бланков с полями, которые взаимосвязаны друг с другом (отоборажают различные разрезы/детали сложной информации) ?

Только гриды/таблицы... Это очень грустно...

ТС, я считаю, что у вас неправильная парадигма.

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

У меня, кстати, в моем конфигураторе (ну какой же разработчик без своего конфигуратора!) есть такая возможность. Но она не получила большого развития, наиболее критические, узловые места оказались в других точках архитектуры.

Так что я пришел к тому, что логика обработки и расчетов пишется на сервере, логика ввода - на клиенте, а конфигуратор выполняет роль презентатора данных, в том числе сложно устроенных. Область работы системы - учетная система финансового толка, комплексная, сочетающа и фронт и бэк, но не бухучет. Конфигуратореможет оживить разные прикладные формы (формы-структуры типа эксплорер с деревом катологов, формы карточки, табличне формы) без кодирования. Но кроме как показа имеющихся данных и ввода новых записей ничего сделать будет нельзя. Для дальнейшего надо кодировать. Чот любопытно, сам конфигуратор форм, позволяющий выполнять все настройки всех типов прикладных форм реализован на самом себе.

Я считаю что этого категорически недостаточно для реализации интерфейса. В конфигураторе обязательно должна быть
1. Настройка разного вида панелей: иерархические стркутуры/деревья/аутланеры..., гриды, карточки с полями.
2. Правила отображение панелей на данные
3. Правила поведения панелей (отключение/скрытие) одних полей или групп при срабатывании определенных условий в других полях.
4. Правила проверки данных при вводе/редактировании.
5. Увязка панелей друг с другом по данным. Размещение панелей в окнах/контейнерах/формах.
6. Команды открытия одних форм из других и/или перехода по формам с сохранением контекста.

пп. 3 и 4 у меня реализованы слабее всего - в них оказалась самая меньшая нужда.

Хорошо, когда в конфигураторе есть готовые универсальные крупноблочные запчасти:
1. Панель (субформа) для вкладывания произвольных аттачментов (файлов, документов, сканов) к бизнес-сущности.
2. Панель (субформа) для генерации ворда по шаблону с подстановкой данных бизнес-сущности (типа слияние ворда).
3. Формирование экселовских книг по шаблонам с использованием данных бизнес-сущности или списка экземпляров сущностей (отчеты)
4. Воркфлоу перехода экземпляра бизнес-сущности по статусам.

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