Здравствуйте, Кирилл Лебедев, Вы писали:

КЛ>Необходимо разработать графический редактор форм, который будет способен создавать и редактировать формы, сохранять их мето-описание в файлах различных форматов и загружать их из файлов различных форматов. Кроме того, необходимо разработать визуализатор (или конструктор) форм, который способен создавать работающие формы на основе их мето-описания.
Что такое метаописание формы?
Описание формы это данные. Те какие контролы, где лежет, что на них написано и тп это данные.
А что на контроле может быть написано, можно ли ему задать шрифт итп это метаданные.

Так вот в твоей архитектуре я нашол только очень плохо спроектированные данные. Никаких метаданных там нет.
Те все матаданные хардкодятся в сериализаторы и дизайнер. Это очень плохо.

Метаданные нужны сериализаторам и дизайнеру для того чтобы они не знали контролы в лицо.
Те у нас есть скомпилированные сериализатор и дизайнер форм.
Нужно добавить еще один контрол так чтобы ни сериализаторы ни дизайнер трогать не пришлось. Те чтобы их даже перекомпилировать не нужно было.

КЛ>Так, структурная модель может быть представлена набором записей такого вида:

КЛ>

КЛ>
1. Parent ID.
   КЛ>
2. ID.
   КЛ>

Не может.
Ибо контролы не всегда просто содержат коллекцию других контролов.
Может быть свойство содержащие вложенный контрол.

КЛ>Визуальная модель может быть представлена набором таких записей:

КЛ>

КЛ>
1. ID.
   КЛ>
2. Type (button, listbox, combobox, checkbox, radiobutton, edit и т.д.).
   КЛ>
3. Text.
   КЛ>
4. Picture.
   КЛ>

Это простите вобще бред.
Думаешь для всех контролов отделаться текстом и картинкой?
Да и некоторым контрола не нужны ни картинки ни текст.

КЛ>Для расположения кнопок на гриде можно использовать вырожденный случай, когда X и Y задают положение ячейки, а Width и Height – всегда равны 1.
Кул хацкер млин. Как у тебя вобще что-то работает если ты так запросто мешаешь теплое с мягким?

КЛ>Если вырожденный случай не подходит, то топологическая модель для грида может быть такой:

А для Dock'а третий, а для Follow четвертый, а я еще их кучу придумаю.

КЛ>Динамическая модель состоит из набора структур такого вида:

КЛ>

КЛ>
1. ID.
   КЛ>
2. Handler.
   КЛ>

Это типа у одного контрола может быть одно событие? Жестоко.

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

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

КЛ>После проведенной нормализации получили мето-описание формы в виде четырех таблиц. Внутренне каждую таблицу в программе можно представить в виде массива структур (не нужны никакие интерфейсы!). Внешне эти таблицы можно представить практически в любом формате – хоть в xml, хоть в базе данных.
Данная модель не жизнеспособна. Перечислять все проблемы очень долго.