Динамическое создание интерфейса формы задачи WorkFlow

[Александр]

А никто не делал что нибудь подобное...
задача такая - есть форма, на которой расположено 10 списков, есть 5 наборов данных (шаблонов) в виде объектов с атрибутами
нужно на форме при выборе того или иного шаблона пересоздать контент формы т.е. обновить все списки, обновить все надписи над списками, погасить те или иные списки, может даже координаты подвигать - ну т.е. практически обновить весь интерфейс в соответствии с данными шаблона прочитанными Selectom из базы

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

может кто нибудь уже занимался этим увлекательным делом - поиском проблем на пустом месте ?

если да - может есть какие нибудь подводные камни?

ps
задача еще интересна тем что все это происходит не на самой форме задачи а на форме фиктивного массива открытого в отдельном окне

[Юрий]

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

[Александр]

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

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

я думал просто оптом ОДНОКРАТНО при выборе того или иного шаблона запустить цепочку запросов на обновление

[Александр]

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

короче вынести или дополнить конструктор форм из кода Лоции создав свой собственный конструктор - на свободно редактируемых объектах базы а почему бы и нет - вот только как нибудь бы пооптимальнее

[Старик Крупский]

Э-э-э... А в чем проблема? Ты же можешь по событию изменения шаблона перерисовать всю форму.. Шаблон можно выбрать здесь же в форме из выпадающего списка. А f_ModifyForm после этого перерисует форму на "раз". А можно и свойствами прямо в форме поиграться. Или я не понял сути проблемы?

[Александр]

Шаблон можно выбрать здесь же в форме из выпадающего списка

что имеется в виду?
а остальное - да взял новые данные для шаблона и перерисовал

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

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

или

2. сделать 'нормальную' форму и расположить на ней только 10 заполненных списков, с текущими зависимостями между собой и перегружать их значения данными из базы в зависимости от одного из 5 шаблонов

может непонятно объяснил, но вот еще проще
1й список имеет 10 значений
2й в зависимости от первого имеет какой то свой список значений
3й в зависимости от 2го имеет свой список
и это все один шаблон

а мне надо 5 и с разными вариантами кто от чего зависит и какое текущее наполнение будет у связанных списков

[Старик Крупский]

Шаблон может быть и объектом. Тогда храним все данные в объекте. Можно вообще все параметры функции f_modifyform хранить в атрибутах этих объектов.
Кстати, когда-то ты решал вопрос об отвязанных атрибутах. А нельзя ли было решить эту задачу через хранение значений в атрибутах служебных объектов? Например, объект1 и у него есть атрибут1 со списком 1.

[Александр]

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

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

а так хранить интерфейс и данные в виде объектов - вроде нормально - но пока еще что-то в голове не укладывается.....

думаю короче

[Александр]

кстати на счет хранения данных в формате функции f_modifyform интересная мысль - спасибо

а еще чего нибудь - в том же духе?

[Старик Крупский]

Не сейчас