Здравствуйте, WolfHound,
В предыдущем сообщении мною был описан подход и эскиз решения, иллюстрирующий подход. Эскиз полностью соответствует тем условиям, которые Вы описали явно. Т.е. если у Вас было что-то в голове, и Вы это не сообщили, то я же не телепат, чтобы догадываться. Тем не менее, приведенный подход, на мой взгляд, вполне работоспособен. Его можно использовать для доводки эскиза до готового решения.
WH>Что такое метаописание формы?
Это вопрос к Вам — Вы же ставили задачу. Если для Вас разница между "данными" и "метаданными" важна, соответственно, ее нужно было и подчеркнуть.
WH>Описание формы это данные. Те какие контролы, где лежет, что на них написано и тп это данные.
WH>А что на контроле может быть написано, можно ли ему задать шрифт итп это метаданные.
Не вижу проблем, которые помешали бы создать еще одну таблицу и поместить туда метаданные. Эту таблицу можно отдельно считывать и редактировать, не затрагивая остальные данные формы.
WH>Метаданные нужны сериализаторам и дизайнеру для того чтобы они не знали контролы в лицо.
WH>Те у нас есть скомпилированные сериализатор и дизайнер форм.
WH>Нужно добавить еще один контрол так чтобы ни сериализаторы ни дизайнер трогать не пришлось. Те чтобы их даже перекомпилировать не нужно было.
И что? Просто добавляете контрол в соответствующую таблицу? Зачем трогать все остальное?
WH>Ибо контролы не всегда просто содержат коллекцию других контролов.
WH>Может быть свойство содержащие вложенный контрол.
Там же написано — Parent ID и ID. А что это — идентификаторы контрола или свойства или чего-нибудь еще — совершенно не важно.
WH>Думаешь для всех контролов отделаться текстом и картинкой?
Перечислите здесь, что еще — кроме текста и картинки — может содержать (отображать) контрол, и я покажу, как можно изменить таблицу.
WH>Да и некоторым контрола не нужны ни картинки ни текст.
При заполнении эти поля можно оставить пустыми.
КЛ>>Для расположения кнопок на гриде можно использовать вырожденный случай, когда X и Y задают положение ячейки, а Width и Height – всегда равны 1.
WH>Кул хацкер млин. Как у тебя вобще что-то работает если ты так запросто мешаешь теплое с мягким?
Не вижу здесь никакого хакерства. Наоборот, я использовал обобщение. Алгоритму расположения все равно,
что располагать и
на чем располагать. Сам алгоритм от этого не изменится — он работает с прямоугольниками.
КЛ>>Если вырожденный случай не подходит, то топологическая модель для грида может быть такой:
WH>А для Dock'а третий, а для Follow четвертый, а я еще их кучу придумаю.
В Вашей постановке задачи ни про Dock, ни про Follow ничего не написано. Но если Вы детально опишите, что это такое, я могу наглядно показать, как и эти вещи укладываются в предложенную модель.
WH>Это типа у одного контрола может быть одно событие? Жестоко.
Вы опять лукавите и предъявляете к эскизу претензии, как к уже готовому решению. Небольшое изменение в таблице, и возможность добавления множества событий для одного контрола обеспечена:
ID (контрола).
Event ID.
Handler.
WH>Кстати я правильно понял что ты в дизайнере предлагаешь держать паралельно контролы используемые дизайнером и вот эти вот твои таблички?
Вы бы по-человечески описали проблему — тогда можно будет говорить о решении.
WH>Еще ты проигнорировал то что присоедененные свойства и события могут быть не только информацией о положении контрола.
Почему проигнорировал? Вы их просто не перечислили. Перечислите, и посмотрим.
WH>Данная модель не жизнеспособна. Перечислять все проблемы очень долго.
Почему же не работоспособна? Вполне работоспособна. Просто либо Вы слишком много требуете от эскиза, либо не полностью описали задачи, решения которых сейчас требуете. Все эти задачи решаемы.
Вы бы привели здесь свою модель, чтобы мы могли с коллегами оценить ее жизнеспособность и проверить на соответствие Вашим же критериям. А то как-то однобоко у Вас все получается.
