Здравствуйте, aka50, Вы писали:
E>>От создания компиляторов я далек. Вот на примере GUI-ев каких-нибудь или сетевого взаимодействия примеры бы какие-нибудь посмотреть бы... A>Ну непосредственно к сетевому коду или гуям в общем-то это слабо прикручивается, там рулит паттерн-матчинг и прочие implicit фишки (если конкретно скала рассматривать), а вот в деле фреймворко-компоненто-строения — вполне себе замечательная технология (хотя и не лишенная недостатков, например в том же компиляторе за счет всех эти self и type образуется довольно сильная связанность и например выцепить отдельно SyntaxAnalyzer без всей остальной ботвы довольно сложно)
Вот не показалось мне, что для фреймворков это дело подходит. Тем более к расширению чего-нибудь внутри фреймворка безе перекомпиляции самого фреймворка. Ну т.е. если на пальцах объяснять: скажем у меня в SObjectizer при вызове события у агента создается объект, реализующий интерфейс event_data_t. Какой именно класс используется для создания этого объекта, снаружи не видно. И в принципе не должно быть видно. Вот и не видно, как пользователь может вмешаться в создание event_data_t и что-нибудь там расширить. Да и зачем это делать так же не понятно.
Тем более, что подобные расширения в динамических языках с открытыми типами делаются вообще очень прозрачно, без заморочек.
A>А вообще надо бы и правда попробывать чтонить более близкое к людям рассмотреть как пример... правда это уже на целую статью тянет, тут одним постом не отделаешься
Вот, кстати, со Scala так постоянно -- какая-то заумность вокруг. Когда читаешь доки по D, Erlang или Nemerle, так сразу понимаешь что к чему и почему. А вот Scala в этом смысле не далеко от Haskell-а ушла
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, aka50, Вы писали:
E>Вот не показалось мне, что для фреймворков это дело подходит. Тем более к расширению чего-нибудь внутри фреймворка безе перекомпиляции самого фреймворка. Ну т.е. если на пальцах объяснять: скажем у меня в SObjectizer при вызове события у агента создается объект, реализующий интерфейс event_data_t.
Данная техника подходит для расширения в _compile-time_ с проверкой типов на этапе компиляции. Не более и не менее (т.е. если ты начнешь пытаться работать event_data из измененного фреймворка — у тебя будет несоотвествие типов).
E>Тем более, что подобные расширения в динамических языках с открытыми типами делаются вообще очень прозрачно, без заморочек.
А с типо-безпасностью у них что будет? Т.е. в данном случае можно гарантировать, метод baseframework.send(baseframework.event_data) и mychangedframework.send(baseframework.event_data) работать не будут, будет ошибка компиляции. В случае с динамическим языком отловишь ты это только в момент выполнения программы.
А вообще не хочется опять сваливаться в спор dynamic vs static. Честно. Данный метод для _сатического_ расширения функционала с контролем типов в момент компиляции (т.е. этакий "static" spring). При этом он не отменяет возможности применения "dynamic" spring. Правда при этом все равно будут проверяться типы и допустим frameworkVer1.event_data и frameworkVer2 extends frameworkVer1 event_data будут не совместимы.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, aka50, Вы писали:
E>Вот, кстати, со Scala так постоянно -- какая-то заумность вокруг. Когда читаешь доки по D, Erlang или Nemerle, так сразу понимаешь что к чему и почему. А вот Scala в этом смысле не далеко от Haskell-а ушла
Просто из разных миров. Я люблю статику и неперевариваю динамику (ну не понимаю я ее ). По этому мне тяжело работать с питоном, а вот в скалу как-то сразу въехал и она мне все больше нравиться... Еще к хаскелю присматриваюсь, уже даже понимать немного его начал, а там с типами вроде как еще хуже
A>Просто из разных миров. Я люблю статику и неперевариваю динамику (ну не понимаю я ее ). По этому мне тяжело работать с питоном, а вот в скалу как-то сразу въехал и она мне все больше нравиться... Еще к хаскелю присматриваюсь, уже даже понимать немного его начал, а там с типами вроде как еще хуже
Здравствуйте, aka50, Вы писали:
D>>С типами в Хаскелле всё хорошо.
A>В скала тоже все отлично, но как видишь есть несогласные
Дело не в несогласии, а в непонимании. Вот нет по Scala пока такой документации, чтобы прочитал и понял -- о, а ведь этого мне по работе-то и не хватало! Как-то с другими языками (Pascal, C++, Java, Ruby, Eiffel, D, Erlang) ситуация совсем другая, поскольку там материалы, ориентированные на практиков. А вот материалы о Scala больше напоминают отчеты о научных исследованиях.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, WolfHound, Вы писали:
WH>Нужно спроектировать модель метаданных, и для примера кнопку и грид.
Резюмируя, можно сформулировать техническое задание в таком виде:
Необходимо разработать графический редактор форм, который будет способен создавать и редактировать формы, сохранять их мето-описание в файлах различных форматов и загружать их из файлов различных форматов. Кроме того, необходимо разработать визуализатор (или конструктор) форм, который способен создавать работающие формы на основе их мето-описания.
Главная полезная функция: Создание, редактирование и визуализация форм.
Для того, чтобы редактировать уже существующую форму редактор форм должен:
Загрузить форму из файла.
Редактировать форму.
Сохранить форму в файле.
Для того, чтобы создать новую форму редактор форм должен:
Создать пустую форму.
Редактировать форму.
Сохранить форму.
Загрузка формы состоит из нескольких операций:
Считывание данных формы из файла.
Создание пустой формы.
Создание и добавление контролов к форме.
Размещение контролов на форме в соответствии с заданным порядком.
Отображение (визуализация) формы и контролов.
Ассоциация обработчиков событий с контролами.
Операция редактирование тоже состоит из нескольких подопераций:
Создание контрола и добавление его к форме.
Удаление контрола (с формы и вообще).
Размещение контрола на форме.
Задание и редактирование визуальных параметров контрола.
Задание обработчика события для контрола.
Для визуализации (отображения) готовой формы в программе визуализатор должен:
Загрузить форму из файла.
Отобразить форму на экране и реагировать на события.
Операция загрузки формы является составной, и она уже была расписана ранее. Описание работы с готовой формой внутри программы выходит за рамки данной задачи. В этом смысле созданная на основе мето-описания форма мало чем отличается от других форм и функционирует, как обычная .NET форма.
Подытоживая, опишем функциональную модель редактора форм (в первом приближении):
Считывание данных формы из файла.
Сохранение данных формы в файле.
Создание пустой формы.
Удаление формы.
Создание контрола.
Удаление контрола.
Добавление контрола к форме.
Удаление контрола из формы.
Размещение контрола на форме.
Размещение всех контролов на форме.
Отображение формы и контролов.
Создание обработчика событий.
Удаление обработчика событий.
Ассоциирование обработчика событий с конкретным контролом.
На основе перечисленных функций, можно выделить такие функциональные группы:
Структурная. К ней относится все то, что связано со структурой (с содержанием контролов внутри формы и внутри других контролов).
Визуальная. Отвечает за создание и визуализацию контролов (за цвет контрола, надпись на кнопочке или картинку).
Топологическая. Отвечает за расположение контролов на форме.
Динамическая. Отвечает за привязку обработчиков событий к конкретным контролам.
Соответственно, на основе каждой из этих групп можно создать модель представления формы. Полностью форма представляется четырьмя моделями.
Так, структурная модель может быть представлена набором записей такого вида:
Parent ID.
ID. Визуальная модель может быть представлена набором таких записей:
ID.
Type (button, listbox, combobox, checkbox, radiobutton, edit и т.д.).
Text.
Picture. Топологическая модель может быть представлена структурами:
ID.
X.
Y.
Width.
Height.
Для расположения кнопок на гриде можно использовать вырожденный случай, когда X и Y задают положение ячейки, а Width и Height – всегда равны 1.
Если вырожденный случай не подходит, то топологическая модель для грида может быть такой:
ID.
Col.
Row. Динамическая модель состоит из набора структур такого вида:
ID.
Handler.
После проведенной нормализации получили мето-описание формы в виде четырех таблиц. Внутренне каждую таблицу в программе можно представить в виде массива структур (не нужны никакие интерфейсы!). Внешне эти таблицы можно представить практически в любом формате – хоть в xml, хоть в базе данных.
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Необходимо разработать графический редактор форм, который будет способен создавать и редактировать формы, сохранять их мето-описание в файлах различных форматов и загружать их из файлов различных форматов. Кроме того, необходимо разработать визуализатор (или конструктор) форм, который способен создавать работающие формы на основе их мето-описания.
Здравствуйте, eao197, Вы писали:
E>Дело не в несогласии, а в непонимании. Вот нет по Scala пока такой документации, чтобы прочитал и понял -- о, а ведь этого мне по работе-то и не хватало! Как-то с другими языками (Pascal, C++, Java, Ruby, Eiffel, D, Erlang) ситуация совсем другая, поскольку там материалы, ориентированные на практиков. А вот материалы о Scala больше напоминают отчеты о научных исследованиях.
Ну да... с доками не очень. Можешь порыться http://scala.sygneca.com, там есть кучка примеров и паттернов, хотя маловато конечно...
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Необходимо разработать графический редактор форм, который будет способен создавать и редактировать формы, сохранять их мето-описание в файлах различных форматов и загружать их из файлов различных форматов. Кроме того, необходимо разработать визуализатор (или конструктор) форм, который способен создавать работающие формы на основе их мето-описания.
Что такое метаописание формы?
Описание формы это данные. Те какие контролы, где лежет, что на них написано и тп это данные.
А что на контроле может быть написано, можно ли ему задать шрифт итп это метаданные.
Так вот в твоей архитектуре я нашол только очень плохо спроектированные данные. Никаких метаданных там нет.
Те все матаданные хардкодятся в сериализаторы и дизайнер. Это очень плохо.
Метаданные нужны сериализаторам и дизайнеру для того чтобы они не знали контролы в лицо.
Те у нас есть скомпилированные сериализатор и дизайнер форм.
Нужно добавить еще один контрол так чтобы ни сериализаторы ни дизайнер трогать не пришлось. Те чтобы их даже перекомпилировать не нужно было.
КЛ>Так, структурная модель может быть представлена набором записей такого вида:
КЛ> КЛ>Parent ID. КЛ>ID. КЛ>
Не может.
Ибо контролы не всегда просто содержат коллекцию других контролов.
Может быть свойство содержащие вложенный контрол.
КЛ>Визуальная модель может быть представлена набором таких записей:
КЛ> КЛ>ID. КЛ>Type (button, listbox, combobox, checkbox, radiobutton, edit и т.д.). КЛ>Text. КЛ>Picture. КЛ>
Это простите вобще бред.
Думаешь для всех контролов отделаться текстом и картинкой?
Да и некоторым контрола не нужны ни картинки ни текст.
КЛ>Для расположения кнопок на гриде можно использовать вырожденный случай, когда X и Y задают положение ячейки, а Width и Height – всегда равны 1.
Кул хацкер млин. Как у тебя вобще что-то работает если ты так запросто мешаешь теплое с мягким?
КЛ>Если вырожденный случай не подходит, то топологическая модель для грида может быть такой:
А для Dock'а третий, а для Follow четвертый, а я еще их кучу придумаю.
КЛ>Динамическая модель состоит из набора структур такого вида:
КЛ> КЛ>ID. КЛ>Handler. КЛ>
Это типа у одного контрола может быть одно событие? Жестоко.
Кстати я правильно понял что ты в дизайнере предлагаешь держать паралельно контролы используемые дизайнером и вот эти вот твои таблички?
Еще ты проигнорировал то что присоедененные свойства и события могут быть не только информацией о положении контрола.
КЛ>После проведенной нормализации получили мето-описание формы в виде четырех таблиц. Внутренне каждую таблицу в программе можно представить в виде массива структур (не нужны никакие интерфейсы!). Внешне эти таблицы можно представить практически в любом формате – хоть в xml, хоть в базе данных.
Данная модель не жизнеспособна. Перечислять все проблемы очень долго.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
В предыдущем сообщении мною был описан подход и эскиз решения, иллюстрирующий подход. Эскиз полностью соответствует тем условиям, которые Вы описали явно. Т.е. если у Вас было что-то в голове, и Вы это не сообщили, то я же не телепат, чтобы догадываться. Тем не менее, приведенный подход, на мой взгляд, вполне работоспособен. Его можно использовать для доводки эскиза до готового решения.
WH>Что такое метаописание формы?
Это вопрос к Вам — Вы же ставили задачу. Если для Вас разница между "данными" и "метаданными" важна, соответственно, ее нужно было и подчеркнуть.
WH>Описание формы это данные. Те какие контролы, где лежет, что на них написано и тп это данные. WH>А что на контроле может быть написано, можно ли ему задать шрифт итп это метаданные.
Не вижу проблем, которые помешали бы создать еще одну таблицу и поместить туда метаданные. Эту таблицу можно отдельно считывать и редактировать, не затрагивая остальные данные формы.
WH>Метаданные нужны сериализаторам и дизайнеру для того чтобы они не знали контролы в лицо. WH>Те у нас есть скомпилированные сериализатор и дизайнер форм. WH>Нужно добавить еще один контрол так чтобы ни сериализаторы ни дизайнер трогать не пришлось. Те чтобы их даже перекомпилировать не нужно было.
И что? Просто добавляете контрол в соответствующую таблицу? Зачем трогать все остальное?
WH>Ибо контролы не всегда просто содержат коллекцию других контролов. WH>Может быть свойство содержащие вложенный контрол.
Там же написано — Parent ID и ID. А что это — идентификаторы контрола или свойства или чего-нибудь еще — совершенно не важно.
WH>Думаешь для всех контролов отделаться текстом и картинкой?
Перечислите здесь, что еще — кроме текста и картинки — может содержать (отображать) контрол, и я покажу, как можно изменить таблицу.
WH>Да и некоторым контрола не нужны ни картинки ни текст.
При заполнении эти поля можно оставить пустыми.
КЛ>>Для расположения кнопок на гриде можно использовать вырожденный случай, когда X и Y задают положение ячейки, а Width и Height – всегда равны 1. WH>Кул хацкер млин. Как у тебя вобще что-то работает если ты так запросто мешаешь теплое с мягким?
Не вижу здесь никакого хакерства. Наоборот, я использовал обобщение. Алгоритму расположения все равно, что располагать и на чем располагать. Сам алгоритм от этого не изменится — он работает с прямоугольниками.
КЛ>>Если вырожденный случай не подходит, то топологическая модель для грида может быть такой:
WH>А для Dock'а третий, а для Follow четвертый, а я еще их кучу придумаю.
В Вашей постановке задачи ни про Dock, ни про Follow ничего не написано. Но если Вы детально опишите, что это такое, я могу наглядно показать, как и эти вещи укладываются в предложенную модель.
WH>Это типа у одного контрола может быть одно событие? Жестоко.
Вы опять лукавите и предъявляете к эскизу претензии, как к уже готовому решению. Небольшое изменение в таблице, и возможность добавления множества событий для одного контрола обеспечена:
ID (контрола).
Event ID.
Handler.
WH>Кстати я правильно понял что ты в дизайнере предлагаешь держать паралельно контролы используемые дизайнером и вот эти вот твои таблички?
Вы бы по-человечески описали проблему — тогда можно будет говорить о решении.
WH>Еще ты проигнорировал то что присоедененные свойства и события могут быть не только информацией о положении контрола.
Почему проигнорировал? Вы их просто не перечислили. Перечислите, и посмотрим.
WH>Данная модель не жизнеспособна. Перечислять все проблемы очень долго.
Почему же не работоспособна? Вполне работоспособна. Просто либо Вы слишком много требуете от эскиза, либо не полностью описали задачи, решения которых сейчас требуете. Все эти задачи решаемы.
Вы бы привели здесь свою модель, чтобы мы могли с коллегами оценить ее жизнеспособность и проверить на соответствие Вашим же критериям. А то как-то однобоко у Вас все получается.
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Это вопрос к Вам — Вы же ставили задачу. Если для Вас разница между "данными" и "метаданными" важна, соответственно, ее нужно было и подчеркнуть.
А для тебе что данные и метаданные одно и тоже?
КЛ>Не вижу проблем, которые помешали бы создать еще одну таблицу и поместить туда метаданные. Эту таблицу можно отдельно считывать и редактировать, не затрагивая остальные данные формы.
Еще раз. Метаданные не у формы. Метаданные у контролов. Причем они прибиты к контролам насмерть ибо это описание того что с этими контролами можно вобще делать.
Имея такое описание мы можем работать с контролом обобщенно.
КЛ>И что? Просто добавляете контрол в соответствующую таблицу? Зачем трогать все остальное?
Какую еще таблицу? Контрол нарисовал Выся Пупкин который не имеет доступа к исходникам системы.
КЛ>Там же написано — Parent ID и ID. А что это — идентификаторы контрола или свойства или чего-нибудь еще — совершенно не важно.
Да блин... наворачивается системка...
КЛ>Перечислите здесь, что еще — кроме текста и картинки — может содержать (отображать) контрол, и я покажу, как можно изменить таблицу.
Да что угодно. Это ограничено только фантазией автора контрола.
КЛ>При заполнении эти поля можно оставить пустыми.
А зачем их вобще для всех заводить?
КЛ>Не вижу здесь никакого хакерства. Наоборот, я использовал обобщение. Алгоритму расположения все равно, что располагать и на чем располагать. Сам алгоритм от этого не изменится — он работает с прямоугольниками.
Те ты таки настаиваешь на этом? И после такого ты утверждаешь что твои программы легко поддерживать?
Дело в том что ты создал очень сильную связь на пустом месте. Теперь если мы захотим что-то изменить поедет все. Спрашивается а оно нам надо?
КЛ>В Вашей постановке задачи ни про Dock, ни про Follow ничего не написано. Но если Вы детально опишите, что это такое, я могу наглядно показать, как и эти вещи укладываются в предложенную модель.
Да я сам знаю как уложить это в твою модель. Я давно понял что ты предлогаешь.
Вот только я категорически против таких методов.
Ибо это все очень тяжело делать.
Ибо при добалении нового типа контейнера да и нового контрола нам придется переделывать ВСЕ! Те совсем ВСЕ!
Нам придется править и все сериализаторы, и менять структуру таблиц в базах. И допиливать дизайнер.
Мой подход этих проблем лишон.
При реализации данной системы проблемы были. Но ни одна из них не связанна с метаданными. Те были проблемы с кривыми контролами (ну не самим же все писать), были проблемы с разной природой различных представлений (win и web ну очень разные). Но небыло проблем с метаданными. Те вобще небыло.
Когда нужен был новый контрол он просто тупо добавлялся.
И ничего править было не нужно.
Ибо система понимет метаданные контрола и по ним все само работает.
И сериализация, и редактор и все что в голову взбредет.
WH>>Кстати я правильно понял что ты в дизайнере предлагаешь держать паралельно контролы используемые дизайнером и вот эти вот твои таблички? КЛ>Вы бы по-человечески описали проблему — тогда можно будет говорить о решении.
Проблема в том что нужно синхронизировать два разных представления одного и тогоже.
Ибо редактор был взят тот что в WinForms. Ну не самому же его писать.
WH>>Еще ты проигнорировал то что присоедененные свойства и события могут быть не только информацией о положении контрола. КЛ>Почему проигнорировал? Вы их просто не перечислили. Перечислите, и посмотрим.
Что перечислить? Все свойства которые один контрол может добавлять другому?
Так я их не знаю. Каждый новый контрол может иметь возможность комунибудь, чегонибудь добавить.
Это не фиксируется при разработке системы.
Добро пожаловать в реальный мир где требования постоянно меняются.
WH>>Данная модель не жизнеспособна. Перечислять все проблемы очень долго. КЛ>Почему же не работоспособна? Вполне работоспособна. Просто либо Вы слишком много требуете от эскиза, либо не полностью описали задачи, решения которых сейчас требуете. Все эти задачи решаемы.
Не подменяй слова.
Данная система не жизниспособна по тому что она не выживет под напором изменений.
КЛ>Вы бы привели здесь свою модель, чтобы мы могли с коллегами оценить ее жизнеспособность и проверить на соответствие Вашим же критериям. А то как-то однобоко у Вас все получается.
Так это же не я предлогаю серебренную пулю.
А ты пока еще не продемонстрировал ничего интересного. Все твои решения это то как нельзя делать никогда.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, 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>А ты пока еще не продемонстрировал ничего интересного. Все твои решения это то как нельзя делать никогда.
На мой взгляд, это уже почти грубость. Я хоть и выдвигал претензии к стилю архитектуры, предлагаемой Вами, но так не говорил. Обычно грубят, когда не хватает аргументации.
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Это зависит от контекста. Вон даже 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>())
КЛ>А если бы Вы эти интерфейсы еще и расписали, я бы наглядно продемонстрировал — на Вашем же примере — что это за проблемы. Так сказать, осязаемо. Но Вы почему-то не захотели этого сделать. Наверное, все-таки боитесь результатов ревью сторонних людей.
Я не привел по тому что хотел посмотреть на твое решение. Без подсказок так сказать.
Это модель метаинформации. Не контролов.
WH>>При реализации данной системы проблемы были. Но ни одна из них не связанна с метаданными. Те были проблемы с кривыми контролами (ну не самим же все писать), были проблемы с разной природой различных представлений (win и web ну очень разные). Но небыло проблем с метаданными. Те вобще небыло. КЛ>Вы бы конкретизировали проблемы, так чтобы коллеги могли понять.
Я надеюсь отличие win от web понятно. А что касается кривизны контролов то тут можно обраться к "продукции" конторы DevExpress.
Эти орлы очень любят завязываться на частности типа твоего предложения о том как нужно организовать лейауты.
КЛ>А никто и не утверждал, что система не будет работать. Утверждалась другое — будет монстроидальный код и сложности с сопровождением. Судя по тому, что код интерфейсов Вы так и не привели, он действительно монстроидален.
Монстроидальна реализация контролов. Но не из-за метаинформации, а из-за скрещивания win с web и объезда дизайна (вернее его полного отсутствия) контролов DevExpress.
WH>>Что перечислить? Все свойства которые один контрол может добавлять другому? КЛ>Да, это было бы хорошо. Или хотя бы перечислите несколько характерных примеров. Абстрактные пожелания как-то плохо воспринимаются.
Ну например контрол который всем другим контролам добавляет свойство ToolTip
WH>>Это не фиксируется при разработке системы. КЛ>Очень плохо.
Это реальная жизнь. Невозможно раз и навсегда зафиксировать требования.
WH>>Добро пожаловать в реальный мир где требования постоянно меняются. КЛ>Предполагаю, что все разнообразие, про которое Вы говорите, сводится к нескольким типовым случаям.
Валидаторы, биндеры, провайдеры контекстных меню и тп.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, 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>Это реальная жизнь. Невозможно раз и навсегда зафиксировать требования.
По-любому требования нужно записывать и сохранять. Даже если они впоследствии меняеются. А чтобы требования менялись поменьше, то нужно как следует поставить задачу. Постановка задачи предполагает формулирование и запись требований, а также — моделирование с целью выявления дополнительных требований.
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Я говорю не о тех контролах, которые присутствуют в редакторе MS Visual Studio, а о том, что даже для большой и сложной программы вряд ли требуется бесконечное число контролов. И рекомендовал Вам обратить внимание на Word или Studio, где контролов (здесь я имею в виду интерфейс этих программ) — ограниченное количество, и весь интерфейс оформлен в едином стиле.
Гы... Где-где это органиченный набор контролов?
WH>>И пытаемся понять как же сюда впишится лейаут который использует для позиционирования контролов скажем сплайны. Те на лейауте задается некая кривая по кторой выстраиваются контролы.
КЛ>Ну, во-первых, привязать контролы к сплайну можно еще и во время дизайна формы. А если такое решение не подходит, то придется разделить операцию размещения на две: позиционирование и масштабирование. Соответственно, для позиционирования потребуется отдельная модель. Итого имеем очень ограниченное расширение модели.
КЛ>А, собственно говоря, что в этом страшного? Ваш код тоже поменяется, если Вы решите размещать контролы вдоль сплайна.
Прежде чем делать такие вот заявления, советую обратить внимание, например, на GTK.
Здравствуйте, Кирилл Лебедев, Вы писали:
WH>>Да я уже устал повторять. Метаданные контролов это описание свойств, событий,... КЛ>Для проектирования нужны конкретные примеры. Нельзя спроектировать дом, не зная, для кого он предназначен.
Что!?!? Еще раз повторить?
КЛ>Я говорю не о тех контролах, которые присутствуют в редакторе MS Visual Studio, а о том, что даже для большой и сложной программы вряд ли требуется бесконечное число контролов. И рекомендовал Вам обратить внимание на Word или Studio, где контролов (здесь я имею в виду интерфейс этих программ) — ограниченное количество, и весь интерфейс оформлен в едином стиле.
Бесконечного не требуется. Но должна быть возможность в любое время добавить любой контрол.
КЛ>Это не так. Вы должны были это понять, если внимательно читали решение. Для того, чтобы создать форму и контролы на ней, нужно выполнить определенную последовательность операций: создание, структурирование, размещение, рисование, ассоциация с обработчиками. Для каждой из этих операций и создана своя модель (при чем — весьма простая).
Так зачем для каждого контрола хранить текст и картинку?
КЛ>А зачем алгоритму размещения знать, что он размещает? Зачем ему нужно знать тип контрола, текст на нем, картинку, обработчики событий и какую-то другую метаинформацию?
Лейауту не нужно знать что за контролы на нем лежат.
Но и загнать все лейауты под одну гребенку не получится.
КЛ>С точки зрения кого разные? С точки зрения контролов — форма или грид — действительно, разные. Но алгоритму размещения об этом неизвестно. Он работает с "сеткой", представленной набором ячеек. В одном случае ячейками являются ячейки грида, в другом случае — пикселы. Что от этого поменяется?
Алгоритм размещения у каждого лейаута свой.
КЛ>Не, сам я смотреть не буду. И так уже много трачу времени на это обсуждение. Если захотите узнать решение, объясните сами. Затем я его опишу.
Я его знаю. И оно мне не интересно. Ибо таки "решения" я прекратил создавать много лет назад.
КЛ>А, собственно говоря, что в этом страшного? Ваш код тоже поменяется, если Вы решите размещать контролы вдоль сплайна.
Мой нет. Я только добавлю новый лейаут. И все. Ни что другое задето не будет.
КЛ>Извините. Так это просто потому, что Ваша иерархия ничего не делает. Т.е. какой-нибудь функциональный код в ней вообще отсутствует. Классы коллекционируют object'ы — только и всего. На языке C++ все Ваши классы и интерфейсы я могу свести к одной записи:
Может просто нужно понять что это такое?
Реально эти интерфейсы позволяют полностью абстрагировать сериализатор и дизайнер от конкретных контролов.
КЛ>Выглядит короче, а смысла столько же. Человек, работающий с Вашими интерфейсами, просто заколебается преобразовывать object'ы в надлежащие типы данных. Я уж не говорю о том, что в Ваш класс можно добавить какой угодно объект, даже тот, который добавлять нельзя, и компилятор это спокойно проглотит, потому что у Вас там object.
Конкретно с этими интерфейсами работают только сериализаторы и дизанеры. Причем это какраз те сущьности которые только с object'ами работать и могут. Иначе их придется завязать на конкретные контролы, а это неприемлемо.
Весь остальной код строго типизирован.
КЛ>Разумеется доступ к этим данным имеет только код визуализации.
А какже сериализаторы? А дизайнеры?
КЛ>ИМХО, такой код только запутывает. В малых дозах он раздражает. А в огромных количествах просто становится несопровождаемым. Не забывайте, что после Вас программу может сопровождать совсем другой программист.
Любой квалифицированный программист знающий C#2 поймет что тут написано вобще не напрягаясь.
КЛ>Если не верите, предлагаю убедится на собственном опыте.
Я легко пишу и читаю на множестве языков. C# один из них.
КЛ>Визуально — различаю. На уровне реализации различий не знаю.
Мда.
А то что на винде сигналы от пользователя приходят мнгновенно, а через инет могут пробиваться секунды известно?
А то что несмотря на тормоза в сети нужно обеспечить максимально конфортную работу пользователю это надеюсь тоже понятно?
Единственный способ сделать работу пользователя конфортной это перетащить максимум кода на жабаскрипт.
КЛ>Я программирую на C++.
А другие языки известны?
Вот я пишу на все что компилируется. Ну или хотябы интерпритируется.
КЛ>Я Вас все же спрашивал о конкретных проблемах, а не об абстрактном (или визуальном) отличии win от web.
Если вы не понимаете отличий между такими разными системами то о чем мы тут вобще говорим?
КЛ>Полагаю, что основная причина монстроидальности — это все-таки преобразование object'а к производным классам. Если бы я на C++ хранил все данные в виде указателей на void, думаю, код тоже был бы монстроидальным.
Не угадал.
При реализации контролов метаданные не нужны и соответственно не используются. Но описываются.
Все интерфейсы контролов строготипизированные.
При работе из кода с контролом те интерфейсы что я продемонстрировал также не нужны.
Они нужны для того чтобы сделать уневерсальные редакторы и сериализоторы.
А так как редакторы и сериализаторы работают с контролами в стиле
foreach (IProperty prop in type.FilteredElements<IProperty>())
{
object value = prop.GetValue(control);
SerializeValue(value, ...);
...
}
То ничего удобнее данной модели не придумать.
Вобще нужно понять что .NET это не С++. И object далеко не тоже самое что void*.
WH>>Ну например контрол который всем другим контролам добавляет свойство ToolTip КЛ>А зачем это делать в виде отдельного контрола?
А что в замен? Хардкодить тултипы везде и всюду?
КЛ>По-любому требования нужно записывать и сохранять. Даже если они впоследствии меняеются. А чтобы требования менялись поменьше, то нужно как следует поставить задачу. Постановка задачи предполагает формулирование и запись требований, а также — моделирование с целью выявления дополнительных требований.
Угу после чего прибегает заказчик с криком "Я тут такую классную фичу придумал! Она нам обязательно нужна!"
А потом еще, и еще, и еше...
И все. Нет твоей идеальной системы.
Ибо система должна быть не идеальной, а устойчивой к изменениям.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, 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 форматов файлов, в которые нужно данные сериализовать. Сколько всего у Вас будет классов свойств?
Вообще, пока совершенно непонятно, как Вы унифицируете метаданные (и метасвойства) разных контролов? И унифицируете ли вообще? Пока что кажется, что для каждого уникального свойства Вы заводите новый класс. И если понадобилось добавить новый контрол с незнакомыми еще свойствами, то просто плодите в коде новые классы. Так?
Все, что Вы пока продемонстрировали, это решение уровня:
Но задача-то не в том, как сделать общий интерфейс для записи различных сущностей в поток. А в том, как унифицировать разные сущности (контролы и их метаданные), чтобы и код не плодить, и не рефакторить его слишком часто из-за неучтенных требований.
WH>А какже сериализаторы? А дизайнеры?
Reader и Writer считывают и записывают структуры данных определенного формата. Но они не имеют доступ к модели целиком.
КЛ>>ИМХО, такой код только запутывает. В малых дозах он раздражает. А в огромных количествах просто становится несопровождаемым. Не забывайте, что после Вас программу может сопровождать совсем другой программист. WH>Любой квалифицированный программист знающий C#2 поймет что тут написано вобще не напрягаясь.
К сожалению, проблемы сопровождения возникают не из-за того, что сопровождающий программист плохо знает язык программирования.
WH>Вот я пишу на все что компилируется. Ну или хотябы интерпритируется.
При чем здесь это? Мы ведь обсуждаем не Ваши способности, а вполне конкретные решения конкретной проблемы.
WH>А что в замен? Хардкодить тултипы везде и всюду?
Позвольте переспросить: Для того, чтобы добавить тултипы ко всем контролам формы, Вы заводите специальный контрол, который осуществляет такое добавление?
КЛ>>По-любому требования нужно записывать и сохранять. Даже если они впоследствии меняеются. А чтобы требования менялись поменьше, то нужно как следует поставить задачу. Постановка задачи предполагает формулирование и запись требований, а также — моделирование с целью выявления дополнительных требований. WH>Угу после чего прибегает заказчик с криком "Я тут такую классную фичу придумал! Она нам обязательно нужна!" WH>А потом еще, и еще, и еше...
После этого Вы спокойно формулируете новые требования к системе, добавляете их к старым требованиям, проверяете их на непротиворечивость. Затем — так же спокойно реализуете и выставляете Заказчику счет за change request.
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Не смотря на модераторский статус, Вы опять пытаетесь грубить. Это выглядит странно, потому что я стараюсь избегать реплик, задевающих Ваше самолюбие. Хотя мог бы, например, написать, что сказали знакомые .NET программисты, посмотрев на Ваш код.
Ну давай. Раскажи что же они сказали.
А лучше давай их самих сюда. Пусть попробуют обосновать свои заявления
Только пусть они предварительно посмотрят на классы PropertyDecriptor и EventDescriptor из .NET фреймворка. И поймут зачем и как они используются.
КЛ>Я спрашивал конкретные примеры. Конкретный пример включает название контрола, примеры свойств (перечислить) и примеры событий.
Зачем это? Я не понимаю.
Дались тебе конкретные контролы. Всеравно завтра прибежит заказчик и скажет хочу супер крутой контрол. Я его вчера в одной проге подсмотрел.
И все. Твоя до придела ужатая система начнет трещать по швам ибо нужно будет перелопатить все(сериализаторы, дизайнеры, возможно другие контролы). А моя даже не заметит появление нового контрола. Ну дописали еще одну сборку с контролом и все.
Модель метаданных от самх контролов не зависит никак.
Болие того модель метаданных такова что может работать с чем угодно, а не только контролами.
Это называется повторное использование кода.
КЛ>Я просил перечислить проблемы, с которыми Вы столкнулись, а не излияния по поводу того, что я не писал HTML-форм. Надо будет — почитаю доку и напишу.
Так это и были проблемы. Системы фундаментально различные. Но их нужно подвести под общий знаменатель для того чтобы прикладникам (люди рисующие формочки сотнями) не приходилось делать одну и туже работу 2 раза. Болие того тонкости отношений win с web их тоже заботить не должны.
КЛ>Мы опять вернулись к тому, с чего начали . "Любых", т.е. принципиально иных контролов (отличных от тех, что уже существуют) на свете не бывает. Ну, разве что Вы изобретете новый вид пользовательского интерфейса. Так вот, если обобщение сделано грамотно, остальные контролы уложатся в модель.
А зачем мне это надо если в мою модель укладываются все контролы? Всключая контролы для принципиально другого UI и вобще то что контролами UI не является.
Так зачем мне частности если у меня общий случай хорошо работает?
КЛ>Я вообще не понимаю, чего Вы тут сравниваете. Ведь, судя по Вашим репликам, КЛ>у Вас каждый контрол воспринимается, как уникальная сущность,
Да. А как иначе? Лепить все в кучу? Спасибо нехочу. Я это проходил очень давно. Не понравилось.
КЛ>и Вы для его обработки (сериализации, размещения или создания) пишете особый код.
Нет.
WH>>Так зачем для каждого контрола хранить текст и картинку? КЛ>А каково Ваше решение? По особому обрабатывать каждый контрол?
Каждый контрол это отдельный класс.
Их можно менять как угодно не затрагивая другие контролы.
Очень важно иметь возможно перетряхнуть один контрол не трогая другие.
КЛ>Слишком сильное утверждение. Пока что никаких аргументов для его обоснования Вы не привели.
Слайн-лейаут.
WH>>Алгоритм размещения у каждого лейаута свой. КЛ>Если layout'ов не так много, то не страшно. А если много, то у Вас получается банальное дублирование кода и данных.
Не получится. Дело в том что лейауты имеют разную логику. И им нужны разные данные и разный код.
Например томуже сплайн-лейауту нужна информация о базовых точках и логика интерполяции.
Ни одному другому лейауту ни то ни другое не нужно.
КЛ>Сериализаторов и дизайнеров несколько или по одной штуке?
Произвольное колличество.
КЛ>Мне вообще непонятно в Вашем решении вот что. Допустим у Вас есть N контролов. С каждым контролом ассоциированы свои метаданные. Допустим, метаданные каждого контрола состоят из M свойств (не уверен, что правильно употребляю это слово). А еще у Вас имеется K форматов файлов, в которые нужно данные сериализовать. Сколько всего у Вас будет классов свойств?
Реализация данной модели метаданных для всех контролов уместилась в 8 классов.
КЛ>Вообще, пока совершенно непонятно, как Вы унифицируете метаданные (и метасвойства) разных контролов? И унифицируете ли вообще? Пока что кажется, что для каждого уникального свойства Вы заводите новый класс. И если понадобилось добавить новый контрол с незнакомыми еще свойствами, то просто плодите в коде новые классы. Так?
Я похож на мазахиста?
При старте программы я прохожусь по свойствам рефлекшеном. Отфильтровываю те свойства которые размечены определенным аттрибутом.
И для каждого свойства создаю экземпляр класса ReflectedProperty.
Вот часть его реализации:
Обрати внимание на методы MakeGetValueProxy/MakeSetValueProxy они возвращают делегат который кидает исключение при вызове если операция не поддерживается либо во время исполнения генерируют код для доступа к конкретному свойству.
Дешево и сердито.
EmitHelper взят из библиотеки BLToolkit. Привет IT
WH>>Любой квалифицированный программист знающий C#2 поймет что тут написано вобще не напрягаясь. КЛ>К сожалению, проблемы сопровождения возникают не из-за того, что сопровождающий программист плохо знает язык программирования.
Дык всеже в чем притензия к совершенно тривиальному коду? Приведу его еще раз.
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;
}
}
Для тех кто знает что такое yield return код кристально ясен. Остальные пусть идут учить C#2.
КЛ>При чем здесь это? Мы ведь обсуждаем не Ваши способности, а вполне конкретные решения конкретной проблемы.
Я хочу узнать сколько языков ты знаешь. Ибо от этого очень сильно зависит то как человек проектирует.
Человек знающий только один язык хорошим архитектором быть не может.
Причем нужно изучать совсем разные языки. Те не ограничиваться C/C++/pascal (C# и жаба пожалуй отдельно от C++ и ко ибо там совсем другой стиль разработки), а еще не забыть про всякие хаскели, форты и прочее.
Вот скажем я недавно написал интерпретатор XML-based языка. Ничего особенного. Простая стековая машина (она даже не полна по Тьюрингу) заточенная под конкретную задачу. У меня на этом языке теперь демоны разговаривают. И я этому очень рад. Ибо таким образом разработчики смежных демонов говорят что им надо моему демону, а не мне (за исключением тех редких случаев когда нет нужных комманд). И они тоже рады ибо для того чтобы изменить логику не нужно трогать меня тк это много дольше чем самому поправить пару строчек в своем коде.
WH>>А что в замен? Хардкодить тултипы везде и всюду? КЛ>Позвольте переспросить: Для того, чтобы добавить тултипы ко всем контролам формы, Вы заводите специальный контрол, который осуществляет такое добавление?
Да. Причем этот контрол не знает в лицо ни один другой контрол. И все работает. Забавно правда?
Кстати не помню как в WinForms 1 но в WinForms 2 сделано также.
КЛ>После этого Вы спокойно формулируете новые требования к системе, добавляете их к старым требованиям, проверяете их на непротиворечивость. Затем — так же спокойно реализуете и выставляете Заказчику счет за change request.
Я да.
А у тебя со "спокойно реализуете" будут большие проблемы.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн