semenarДак в том -то и идея. Чтобы сделать универсальную форму на приложение.
Не ты первый, не ты последний "загорелся" этой идеей. Только вот она не выдерживает столкновения с "прозой жизни".

semenarЕсть предположим под Ораклом 60 view. Так неохота писать 60 форм! Проже сделать одну. Ведь ввод, корректировка, удаление поиск имеет один синтаксис практически. Меняется только название таблицы или вьювера. Задача "облегчить" жизнь программиста.
Ну, ты "крут". Это у тебя 60 абсолютно одинаковых форм? Т.е. никаких новых взаимосвязей между объектами? Если выписываешь накладную или счет-фактуры - никакой разницы в процессе ввода? Ничего не надо проверять ДО попытки сохранения внесенных изменений?

Ты попробуй создать "обычные" формы и посмотри какие взаимосвязи между объектами этой формы тебе придется организовывать. Ни за что не поверю, что у тебя будет "все одинаково". Наверняка начнуться проблемы типа "если вот эта форма, то при нажатии вот этой птички надо выделить цветом вот это, а если другая форма, то вот это".

Сделать "универсальный" интерфейс в принципе можно, но за счет резкого ограничения этого самого интерфейса. При этом "сопровождение" этого универсального интерфейса выльется в сплошную головную боль. Надо каждое пожелание пользователя в одной конкретной форме увязывать с тем, а как это его пожелание отразится на остальных 59 формах.

Т.е. ты не облегчишь, а резко усложнишь жизнь программиста.

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

Если под "унификацией" понимается единный стиль оформления форм, то это вовсе не значит, что для организации одинакового стиля в каждом конкретном случае потребуется однаковый код его формирования.

1024на счёт "резкого" ограничения - наверна не всё так плохо.
Зависит от круга решаемых задач. Если интерфейс - дело второстепенное (например, при подготовке отчетов), то пожалуйста. А если интерфейс - это существенная часть работы (заполнение документов), то при таком "универсальном" интерфейсе будешь спотыкаться на каждом шагу и материть разработчика этого безобразия.

1024"сопровождение" этого универсального интерфейса выльется в сплошную головную
боль. Надо каждое пожелание пользователя в одной конкретной форме увязывать
с тем, а как это его пожелание отразится на остальных 59 формах.
===================================
непонятно как это связано. У меня например интерфейс может быть разным для
каждого пользователя а данные и логика едины для всех и всегда
Я имел в виду, что если в процессе развития приложения потребуется добавить не просто новое поле, но некий взимосвязанный с этим полем интерфейс, то это приведет к большим проблемам.

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

1024
Я имел в виду, что если в процессе развития приложения потребуется добавить
не просто новое поле, но некий взимосвязанный с этим полем интерфейс, то это
приведет к большим проблемам.
===============
не так уж это и сложно реализовать
Да. Один раз. А если надо в каждой из этих 60 форм? Напомню, речь идет об универсальном классе. Т.е. все возможное многообразие интерфейса необходимо "впихнуть" в один класс.

PS:
Кстати, насчет "облегчения работы программиста". А как будут обстоять дела с позиционированием новых объектов (координаты)? Я уже как-то привык к дизайнерам. Мышкой поставил обект куда надо и все. А при такой "унификации" опять высчитывать позицию на калькуляторе?

PPS:
Если это все настолько просто, то почему до сих пор такой подход не реализован в промышленных ERP-системах? Или я просто не в курсе?

Имею в виду не элементы такого подхода для второстепенных фором (вроде подготовки отчетов), а именно реализация для основных рабочих форм (заполнение основных документов).