Взываю к коллективному разуму Мастеров! Работаем в динамике.

← →
Bezsonov Yuri © (2004-01-09 11:47) [0]

Приветствую Всех!
С увеличением количества таблиц в БД растет и количество форм в проекте. И со временем назревает необходимость в динамическом формировании интерфейса приложения (меню, формы и т.д.) на основании данных а БД.
И при попытке создания такого приложения-конструктора возникает много вопросов. Но наверно у многих в практике возникали подобные проекты и есть наработанные решения или идеи, может кто подскажет?
И если с самими данными и их отображением динамически все достаточно понятно, просто требует хорошей проработки структуры таблиц для метаданных, то к вопросу где и как хранить обработчики событий не очень понятно как и подойти.
У кого какие есть идеи? Может есть уже отработанные технологии? или эта затея бесперспективна?

← →
Sergey13 © (2004-01-09 11:50) [1]

2Bezsonov Yuri © (09.01.04 11:47)
>И со временем назревает необходимость в динамическом формировании интерфейса приложения (меню, формы и т.д.) на основании данных а БД.
У меня не назревает. ИМХО, это тупик. Чем это лучше то?

← →
rootim (2004-01-09 11:53) [2]

>или эта затея бесперспективна?
скорее всего так и есть...
Конструктор имхо можно и нужно использовать, например для поиска.. или что-то подобное.
Лично я не нагромождаю кучей формочек в один проект, делю функционал на АРМ и пишу модулями, которые при необходимости можно соединять в под одним приложением.

← →
Bezsonov Yuri © (2004-01-09 12:28) [3]

некоторые возможные преимущества такого подхода в том, что не нужна постоянная перекомпиляция проекта, т.е. изменения можно вносить непосредственно у заказчика.
И даже если идея полной динамики бесперспективна, то как вы поступаете с кучей одинонакых справочников типа REC_ID NAME SHORT_NAME, которые различаются только информацией, сливаете все в одну табличку или как?

← →
Academic © (2004-01-09 12:37) [4]

Я думаю, что выход в создании отдельных тематических АРМ со связью по базе данных.

← →
Nikolay M. © (2004-01-09 12:44) [5]

Как вариант - хранить новые формы в dfm-ках на сервере, а функционал - в дллках или СОМ-объектах, тоже хранящихся на сервере и подтягивающихся по мере надобности.

Но, ИМХО, это все высасывание проблем из пальца на ровном месте.

← →
Bezsonov Yuri © (2004-01-09 12:46) [6]

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

← →
int64 (2004-01-09 12:46) [7]

Можно юзать XML. На ibase.ru был пример.

← →
HSolo © (2004-01-09 12:49) [8]

> как вы поступаете с кучей одинонакых справочников типа REC_ID NAME SHORT_NAME, которые различаются только информацией, сливаете все в одну табличку или как?

Например, так: делаем форму - обработчик всех таких справочников. У нее есть private-переменная - имя таблицы; если поля во всех справочниках называются единообразно, то этого достаточно. Переопределяем конструктор, чтобы он принимал параметр - имя таблицы и укладывал его в ту самую переменную. Запросы на insert/update/delete/refresh формируем в run-time (в OnCreate, к примеру); настройки отображения - по вкусу :)

← →
Bezsonov Yuri © (2004-01-09 12:54) [9]

если хранить в БД формы, то это действительно приобретение проблем, но вся идея в том чтобы формы генерились на основе базовой формы в проекте и метаданных в БД

← →
Academic © (2004-01-09 13:15) [10]

Не может быть абсолютных программ, учитывающих все. Если заказчик требует этого, то он сам не знает что хочет.

← →
Bezsonov Yuri © (2004-01-09 13:17) [11]

to HSolo >
а если справочник отличается от базового, то для него делаем отдельную форму в проекте или все таки как-то динамически?

← →
Alex_Bredin © (2004-01-09 13:24) [12]

я, например, с формами-справочниками вообще не парюсь- давно написана процедура, которая в качестве параметра получает датасет,который надо редактировать, анализирует его структуру, и динамически создает форму с нужными компонентами(boolean-DBCheckBox,string- DBEdit, итп).
Получается очень прилично.
Удачи

← →
Bezsonov Yuri © (2004-01-09 13:24) [13]

Я и не хочу программу учитывающую абсолютно все. Просто если есть задача написать для каждого отдела хранилище документов, но у каждого из них свои параметры (для секретаря входящие/исходящие и пр., для технарей - полка, инв. номер и пр), то не перспективнее ли написать движок, который будет визуализировать описанные в БД метаданные?

to Alex_Bredin © (09.01.04 13:24) [12]
а если у справочника есть ссылки на другие справочники, которые должны заполнять dbComboBox, то вы тоже это реализуете динамически или это работает только для простых таблиц вида select * from table?

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

> Bezsonov Yuri © (09.01.04 13:32) [14]
> to Alex_Bredin © (09.01.04 13:24) [12]
> а если у справочника есть ссылки на другие справочники,
> которые должны заполнять dbComboBox, то вы тоже это реализуете
> динамически или это работает только для простых таблиц вида
> select * from table?

это тоже динамически.Это нетрудно- главное правильно описать метаданные

> Academic © (09.01.04 13:33) [15]
> Описать в базе данных структуру форм, события, создать какой-то
> язык для настройки этих данных много тяжелее, чем разратотать
> конкретную небольшую программу для определенного рабочего
> места.

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

> to Alex_Bredin © (09.01.04 13:36) [16]

вы в метаданных описываете только названия полей для отображения или как-то храните сам текст запроса для выборки/редактирования или все разбираете на основании данных таблицы которую редактируем?

Взываю к коллективному разуму Мастеров! Работаем в динамике. Найти похожие ветки