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

WH>Я его знаю. И оно мне не интересно. Ибо таки "решения" я прекратил создавать много лет назад.

КЛ>>Я программирую на C++.
WH>А другие языки известны?

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

Не смотря на модераторский статус, Вы опять пытаетесь грубить. Это выглядит странно, потому что я стараюсь избегать реплик, задевающих Ваше самолюбие. Хотя мог бы, например, написать, что сказали знакомые .NET программисты, посмотрев на Ваш код.

Ваша "способность" отвечать на вопросы так же поражает. Вот несколько примеров:

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

Я спрашивал конкретные примеры. Конкретный пример включает название контрола, примеры свойств (перечислить) и примеры событий. И таких примеров нужно несколько.

Еще раз повторю, то, что понятно Вам, не факт, что понятно Вашему собеседнику.

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

Я просил перечислить проблемы, с которыми Вы столкнулись, а не излияния по поводу того, что я не писал HTML-форм. Надо будет — почитаю доку и напишу.

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

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

WH>Так зачем для каждого контрола хранить текст и картинку?
А каково Ваше решение? По особому обрабатывать каждый контрол?

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

WH>Алгоритм размещения у каждого лейаута свой.
Если layout'ов не так много, то не страшно. А если много, то у Вас получается банальное дублирование кода и данных.

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

WH>Может просто нужно понять что это такое?
WH>Реально эти интерфейсы позволяют полностью абстрагировать сериализатор и дизайнер от конкретных контролов.
void * тоже помогает "абстрагировать".

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

Мне вообще непонятно в Вашем решении вот что. Допустим у Вас есть N контролов. С каждым контролом ассоциированы свои метаданные. Допустим, метаданные каждого контрола состоят из M свойств (не уверен, что правильно употребляю это слово). А еще у Вас имеется K форматов файлов, в которые нужно данные сериализовать. Сколько всего у Вас будет классов свойств?

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

Все, что Вы пока продемонстрировали, это решение уровня:

std::vector<void *> vec;

Ну, на крайний случай —

class Object
{
public:
   virtual Object() {}
   virtual Read(istream & is) = 0;
   virtual Write(ostream & os) const = 0;
};

std::vector<Object *> vec;

Только зачем-то наплодили лишних интерфейсов.

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

WH>А какже сериализаторы? А дизайнеры?
Reader и Writer считывают и записывают структуры данных определенного формата. Но они не имеют доступ к модели целиком.

КЛ>>ИМХО, такой код только запутывает. В малых дозах он раздражает. А в огромных количествах просто становится несопровождаемым. Не забывайте, что после Вас программу может сопровождать совсем другой программист.
WH>Любой квалифицированный программист знающий C#2 поймет что тут написано вобще не напрягаясь.
К сожалению, проблемы сопровождения возникают не из-за того, что сопровождающий программист плохо знает язык программирования.

WH>Вот я пишу на все что компилируется. Ну или хотябы интерпритируется.
При чем здесь это? Мы ведь обсуждаем не Ваши способности, а вполне конкретные решения конкретной проблемы.

WH>А что в замен? Хардкодить тултипы везде и всюду?
Позвольте переспросить: Для того, чтобы добавить тултипы ко всем контролам формы, Вы заводите специальный контрол, который осуществляет такое добавление?

КЛ>>По-любому требования нужно записывать и сохранять. Даже если они впоследствии меняеются. А чтобы требования менялись поменьше, то нужно как следует поставить задачу. Постановка задачи предполагает формулирование и запись требований, а также — моделирование с целью выявления дополнительных требований.
WH>Угу после чего прибегает заказчик с криком "Я тут такую классную фичу придумал! Она нам обязательно нужна!"
WH>А потом еще, и еще, и еше...
После этого Вы спокойно формулируете новые требования к системе, добавляете их к старым требованиям, проверяете их на непротиворечивость. Затем — так же спокойно реализуете и выставляете Заказчику счет за change request.