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

WH>А для тебе что данные и метаданные одно и тоже?
Это зависит от контекста. Вон даже wikipedia утверждает, что не существует единственного формального определения термина метаданные. Откуда ж я знаю, что Вы имеете в виду?

WH>Еще раз. Метаданные не у формы. Метаданные у контролов. Причем они прибиты к контролам насмерть ибо это описание того что с этими контролами можно вобще делать.
WH>Имея такое описание мы можем работать с контролом обобщенно.
Ну, форму в некотором роде тоже можно рассматривать в виде контрола. В общем, не важно. Вот и привели бы примеры метаданных контрола. А раз не привели — то чего же пенять?

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

КЛ>>Там же написано — Parent ID и ID. А что это — идентификаторы контрола или свойства или чего-нибудь еще — совершенно не важно.
WH>Да блин... наворачивается системка...
Вот это, как раз, и называется абстрагированием, т.к. для описания структуры формы (или контрола) — что в чем содержится — совершенно не важен тип конкретных объектов. Т.е. в рамках конкретной задачи — структурирования — мы абстрагируемся от несущественных для этой задачи деталей.

КЛ>>Перечислите здесь, что еще — кроме текста и картинки — может содержать (отображать) контрол, и я покажу, как можно изменить таблицу.
WH>Да что угодно. Это ограничено только фантазией автора контрола.
Даже в MS Visual Studio или в MS Word'е ограниченное количество контролов. При всем уважении, не думаю, что у Вас система как-то резко сложнее.

КЛ>>При заполнении эти поля можно оставить пустыми.
WH>А зачем их вобще для всех заводить?
Для того, чтобы не плодить сущностей сверх необходимого.

КЛ>>Не вижу здесь никакого хакерства. Наоборот, я использовал обобщение. Алгоритму расположения все равно, что располагать и на чем располагать. Сам алгоритм от этого не изменится — он работает с прямоугольниками.
WH>Те ты таки настаиваешь на этом? И после такого ты утверждаешь что твои программы легко поддерживать?
А Вы голословно не бросайтесь такими утверждениями. Возьмите конкретный пример и разберите, где и какие сложности возникнут.

WH>Дело в том что ты создал очень сильную связь на пустом месте. Теперь если мы захотим что-то изменить поедет все. Спрашивается а оно нам надо?
Что это за связь и в чем она состоит? А вообще-то, я очень сильно сомневаюсь, что layout алгоритм как-то сильно изменится в ближайшие лет 10 — 20. Оперирует он прямоугольниками и боксами и будет оперировать еще долго. Сильно сомневаюсь, что для расположения контролов на форме Вы будете оперировать тетраэдрами.

КЛ>>В Вашей постановке задачи ни про Dock, ни про Follow ничего не написано. Но если Вы детально опишите, что это такое, я могу наглядно показать, как и эти вещи укладываются в предложенную модель.
WH>Да я сам знаю как уложить это в твою модель. Я давно понял что ты предлогаешь.
Если поняли, то и хорошо. Значит еще одно возражение снимается. С другой стороны, если все-таки непонятно, то лучше, наверное, рассказать и про Dock, и про Follow. Для профилактики от неверного понимания.

WH>Вот только я категорически против таких методов.
WH>Ибо это все очень тяжело делать.
WH>Ибо при добалении нового типа контейнера да и нового контрола нам придется переделывать ВСЕ! Те совсем ВСЕ!
WH>Нам придется править и все сериализаторы, и менять структуру таблиц в базах. И допиливать дизайнер.
Вы приводите возражения, не приводя примеры. Взяли бы да и разобрали конкретный пример. Какой контейнер добавим? Что при этом поменяется? "ВСЁ" — это что? Говорите предметно.

Лично у меня мнение, что, наоборот, ничего менять не придется, т.к. модель содержит только те данные, которые нужны для алгоритма размещения. А если алгоритм размещения при добавлении нового контейнера не поменяется (что очень вероятно), то и данные менять не придется.

WH>Мой подход этих проблем лишон.
Если судить по иерархии интерфейсов, которую Вы привели, то проблем там хватает. При чем — с избытком. А если бы Вы эти интерфейсы еще и расписали, я бы наглядно продемонстрировал — на Вашем же примере — что это за проблемы. Так сказать, осязаемо. Но Вы почему-то не захотели этого сделать. Наверное, все-таки боитесь результатов ревью сторонних людей.

WH>При реализации данной системы проблемы были. Но ни одна из них не связанна с метаданными. Те были проблемы с кривыми контролами (ну не самим же все писать), были проблемы с разной природой различных представлений (win и web ну очень разные). Но небыло проблем с метаданными. Те вобще небыло.
Вы бы конкретизировали проблемы, так чтобы коллеги могли понять.

WH>Когда нужен был новый контрол он просто тупо добавлялся.
WH>И ничего править было не нужно.
WH>Ибо система понимет метаданные контрола и по ним все само работает.
WH>И сериализация, и редактор и все что в голову взбредет.
А никто и не утверждал, что система не будет работать. Утверждалась другое — будет монстроидальный код и сложности с сопровождением. Судя по тому, что код интерфейсов Вы так и не привели, он действительно монстроидален.

WH>>>Еще ты проигнорировал то что присоедененные свойства и события могут быть не только информацией о положении контрола.
КЛ>>Почему проигнорировал? Вы их просто не перечислили. Перечислите, и посмотрим.
WH>Что перечислить? Все свойства которые один контрол может добавлять другому?
Да, это было бы хорошо. Или хотя бы перечислите несколько характерных примеров. Абстрактные пожелания как-то плохо воспринимаются.

WH>Так я их не знаю. Каждый новый контрол может иметь возможность комунибудь, чегонибудь добавить.
А зачем контролам добавлять что-то другим контролам?

WH>Это не фиксируется при разработке системы.
Очень плохо.

WH>Добро пожаловать в реальный мир где требования постоянно меняются.
Предполагаю, что все разнообразие, про которое Вы говорите, сводится к нескольким типовым случаям.

WH>Данная система не жизниспособна по тому что она не выживет под напором изменений.
А на мой взгляд — вполне работоспособна и жизнеспособна. И напор изменений с ней ничего не сделает. Если у Вас иное мнение, то, пожалуйста, привидите пример изменения, который ее разрушит.

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

WH>А ты пока еще не продемонстрировал ничего интересного. Все твои решения это то как нельзя делать никогда.
На мой взгляд, это уже почти грубость. Я хоть и выдвигал претензии к стилю архитектуры, предлагаемой Вами, но так не говорил. Обычно грубят, когда не хватает аргументации.