Я вот думал, в каком случае может понадобиться "универсальный" интерфейс?
Ну, например если люди клепают отчеты (типа очень много отчетов). У каждого отчета - свои параметры, следовательно своя форма. Ну или часто появляются каки-либо новые сущности (или новые типы).
Кстати, простые формы легко могут быть описаны XML. Результатом работы - тоже может быть XML. XML может быть разложен по нескольким таблицам (XML Sredding). Базы из большой тройки - Oracle, MS SQL, DB2 - позволяют это делать. (Только что-то это сильно напоминает Web-приложения. )
Но в любом случае, любое приложение выиграет если будет позволять строить (и даже генерировать) произвольные пользовательские формы. Т.е. хранить описание форм в виде XML в базе данных и иметь единственный exe который эту всю байду обрабатывает.

Не знаю найдутся ли смельчаки, которые смогут (и возьмутся) профессионально все это реализовать.

softwarer gardenmanКстати, простые формы легко могут быть описаны XML.
Я не вижу особого смысла в XML, когда есть DFM.

gardenmanНо в любом случае, любое приложение выиграет если будет позволять строить (и даже генерировать) произвольные пользовательские формы. Т.е. хранить описание форм в виде XML в базе данных и иметь единственный exe который эту всю байду обрабатывает.
Хм. Во-первых, "т.е." чуть сильно сказано. Во-вторых, стоит упомянуть, что этот подход называется "тонкий клиент" и само собой, решит далеко не все задачи (первый приходящий в голову пример - форма телефонного справочника, ловившая извещение о приходе-уходе сотрудников (проходе через турникеты)).

Такой подход безусловно возможен, и безусловно имеет свою применимость, где-нибудь в области веб-интерфейса.

Основной недостаток WEB интерфейса - закрыл окно браузера - введенные данные накрылись медным тазом. Необходим опять же WEB-server. Грубо говоря - трехзвенка получается. А тут другая идея на поверхности - форма (вместе с дефолтными данными) может быть не только из WEB сервера получена, но и из любого сограненного на диске XML файла, из базы данных, по почте, или из менеджера очередей (если он был отвалидирован с помощью соответствующей XML-схемы). Самое ужасное в WEB-интерфейсе - это его ублюдочность и тормознутость. Попробуте реализовать paging или загрузить в ComboBox справочник в 10000 опций - не думаю что с таким грузом юзеры будут пищать от восторга. Т.е. нужна гибкость (у WEВ тоже не очень) + перфоменс.
И, опять же - это не для сложных форм, а для простых.

2 softwarer
А что такое DFM, можно ссылочку? (неграмотный я)

1024 авторСамое ужасное в WEB-интерфейсе - это его ублюдочность и тормознутость. Попробуте реализовать paging или загрузить в ComboBox справочник в 10000 опций

вместо "WEB-интерфейсе" можно подставить "delphi-интерфейс" например. Или "Motif-интерфейс"

Но правильно называть это "плохой интерфейс". А кал можно сделать на чём угодно. Плохому танцору всегда что-то мешает

Естественно это правда. Стандартыми контролами и стандартными фичами, которые идут с тем же .Net путевую прогу не написать. Придется свои контролы разрабатывать или модифицировать (если получится) чужие. Для учетной системы нужно ведь не просто понятие "поле ввода", а нужно понятие "поле ввобда корреспондента" с прицепленным справочником и т.д. и т.п. Пусть таких контролов будет 2-3 десятка, и пусть они будут написаны конкретно (типа С++) и XML их будет тока склеивать. Таким образом получим пефоменс как у двузвенки и гибкость как у веб.