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

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

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

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

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

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

КЛ>>Что это за связь и в чем она состоит?
WH>В том что ты связал два совершенно разных лейаута.
WH>Зачем?
С точки зрения кого разные? С точки зрения контролов — форма или грид — действительно, разные. Но алгоритму размещения об этом неизвестно. Он работает с "сеткой", представленной набором ячеек. В одном случае ячейками являются ячейки грида, в другом случае — пикселы. Что от этого поменяется?

WH>Так давай разделять лейауты. И рендер. Это разные вещи.
Под рендером обычно понимается рисование, под layout'ом — размещение. А что Вы понимаете под этими терминами? И где я их смешиваю?

WH>Про Follow можешь посмотреть в WinForms2
Не, сам я смотреть не буду. И так уже много трачу времени на это обсуждение. Если захотите узнать решение, объясните сами. Затем я его опишу.

WH>И пытаемся понять как же сюда впишится лейаут который использует для позиционирования контролов скажем сплайны. Те на лейауте задается некая кривая по кторой выстраиваются контролы.

Ну, во-первых, привязать контролы к сплайну можно еще и во время дизайна формы. А если такое решение не подходит, то придется разделить операцию размещения на две: позиционирование и масштабирование. Соответственно, для позиционирования потребуется отдельная модель. Итого имеем очень ограниченное расширение модели.

А, собственно говоря, что в этом страшного? Ваш код тоже поменяется, если Вы решите размещать контролы вдоль сплайна.

WH>

Изменение, добавление или удаление отдельного атрибута приводит к реорганизации иерархии.

WH>Вот только после того как эту иерархию утрясли никаких изменений больше не требовалось.

Извините. Так это просто потому, что Ваша иерархия ничего не делает. Т.е. какой-нибудь функциональный код в ней вообще отсутствует. Классы коллекционируют object'ы — только и всего. На языке C++ все Ваши классы и интерфейсы я могу свести к одной записи:

std::vector<void *> vec;

Выглядит короче, а смысла столько же. Человек, работающий с Вашими интерфейсами, просто заколебается преобразовывать object'ы в надлежащие типы данных. Я уж не говорю о том, что в Ваш класс можно добавить какой угодно объект, даже тот, который добавлять нельзя, и компилятор это спокойно проглотит, потому что у Вас там object.

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

Разумеется доступ к этим данным имеет только код визуализации.

WH>А у меня все as расположены в методе класса реализующиго IType
WH>

WH>        public IEnumerable<T> FilteredElements<T>() where T : class, IElementBase
WH>        {
WH>            foreach (IElementBase element in m_Elements)
WH>            {
WH>                T filteredElement = element as T;
WH>                if (filteredElement != null)
WH>                    yield return filteredElement;
WH>            }
WH>        }
WH>

ИМХО, такой код только запутывает. В малых дозах он раздражает. А в огромных количествах просто становится несопровождаемым. Не забывайте, что после Вас программу может сопровождать совсем другой программист. Если не верите, предлагаю убедится на собственном опыте.

WH>Я не привел по тому что хотел посмотреть на твое решение. Без подсказок так сказать.
А где ж тут подсказки? Непонятно, за что Ваша модель отвечает. И непонятно, что она хранит. Одни сплошные object'ы.

WH>Это модель метаинформации. Не контролов.
Кошмар!

WH>Я надеюсь отличие win от web понятно. А что касается кривизны контролов то тут можно обраться к "продукции" конторы DevExpress.

Визуально — различаю. На уровне реализации различий не знаю. Я программирую на C++.

Я Вас все же спрашивал о конкретных проблемах, а не об абстрактном (или визуальном) отличии win от web.

WH>Монстроидальна реализация контролов. Но не из-за метаинформации, а из-за скрещивания win с web и объезда дизайна (вернее его полного отсутствия) контролов DevExpress.

Полагаю, что основная причина монстроидальности — это все-таки преобразование object'а к производным классам. Если бы я на C++ хранил все данные в виде указателей на void, думаю, код тоже был бы монстроидальным.

WH>Ну например контрол который всем другим контролам добавляет свойство ToolTip
А зачем это делать в виде отдельного контрола?

WH>>>Это не фиксируется при разработке системы.
КЛ>>Очень плохо.
WH>Это реальная жизнь. Невозможно раз и навсегда зафиксировать требования.
По-любому требования нужно записывать и сохранять. Даже если они впоследствии меняеются. А чтобы требования менялись поменьше, то нужно как следует поставить задачу. Постановка задачи предполагает формулирование и запись требований, а также — моделирование с целью выявления дополнительных требований.