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

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

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

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

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

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

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

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

КЛ>Что это за связь и в чем она состоит?
В том что ты связал два совершенно разных лейаута.
Зачем?

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

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

КЛ>Вы приводите возражения, не приводя примеры. Взяли бы да и разобрали конкретный пример. Какой контейнер добавим? Что при этом поменяется? "ВСЁ" — это что? Говорите предметно.
Дык берем собственно

Топологическая модель может быть представлена структурами:

ID.
X.
Y.
Width.
Height.

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

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

КЛ>Если судить по иерархии интерфейсов, которую Вы привели, то проблем там хватает. При чем — с избытком.
И ни одна из них не была озвучена.

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

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

Злоупотребление оператором преобразования типов (dynamic_cast в C++ или as в C#) и, как результат, нарушение LSP.

А в твоей системе вобще все открыто. Приходи к хочешь. Бери что хочешь. Меняй что хочешь. И никто не узнает. Ибо инкапсуляции нет ваще.

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

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

И используется както так

            foreach (IProperty prop in type.FilteredElements<IProperty>())

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

    public interface IAttachedElement : IElementBase
    {
        bool Recursive { get; }
        bool CanAttach(object owner, object instance);
    }

    public interface IAttachedEvent : IEventBase, IAttachedElement
    {
        void AddEventHandler(object owner, object instance, Delegate handler);
        void RemoveEventHandler(object owner, object instance, Delegate handler);
    }

    public interface IAttachedProperty : IPropertyBase, IAttachedElement
    {
        object GetValue(object owner, object instance);
        void SetValue(object owner, object instance, object value);
        void AddValueChanged(object owner, object instance, EventHandler handler);
        void RemoveValueChanged(object owner, object instance, EventHandler handler);
        bool CanResetValue(object owner, object instance);
        void ResetValue(object owner, object instance);
        bool ShouldSerializeValue(object owner, object instance);
    }

    public interface IDomain
    {
        IType GetType(Type type);
    }

    public interface IElement : IElementBase
    {
    }

    public interface IElementBase
    {
        string Name { get; }
        IType Owner { get; }
    }

    public interface IEvent : IEventBase, IElement
    {
        void AddEventHandler(object instance, Delegate handler);
        void RemoveEventHandler(object instance, Delegate handler);
    }

    public interface IEventBase : IElementBase
    {
        IType EventHandlerType { get; }
    }

    public interface IProperty : IPropertyBase, IElement
    {
        object GetValue(object instance);
        void SetValue(object instance, object value);
        void AddValueChanged(object instance, EventHandler handler);
        void RemoveValueChanged(object instance, EventHandler handler);
        bool CanResetValue(object instance);
        void ResetValue(object instance);
        bool ShouldSerializeValue(object instance);
    }

    public interface IPropertyBase : IElementBase
    {
        IType PropertyType { get; }
        bool CanRead { get; }
        bool CanWrite { get; }
    }

    public interface IType
    {
        string Name { get; }
        Type SystemType { get; }
        IType[] BaseTypes { get; }
        IDomain Domain { get; }
        IEnumerable<T> FilteredElements<T>()
            where T : class, IElementBase;
        T Find<T>(string name)
            where T : class, IElementBase;
        bool IsExtended { get; }
    }

Это модель метаинформации. Не контролов.

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

КЛ>А никто и не утверждал, что система не будет работать. Утверждалась другое — будет монстроидальный код и сложности с сопровождением. Судя по тому, что код интерфейсов Вы так и не привели, он действительно монстроидален.
Монстроидальна реализация контролов. Но не из-за метаинформации, а из-за скрещивания win с web и объезда дизайна (вернее его полного отсутствия) контролов DevExpress.

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

WH>>Это не фиксируется при разработке системы.
КЛ>Очень плохо.
Это реальная жизнь. Невозможно раз и навсегда зафиксировать требования.

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