Итак. Есть объектная модель, состоящая из сотни классов в которых присутствуют свойства и методы.
Задача. Надо отображать и редактировать объекты этой модели.

Строим универсальный браузер. Используем Reflection.
В атрибуты классов, свойств и методов добавляем их наименования и описания на всех нужных нам язывах.
Опционно добавляем варианты возможных значений, диапазон допустимых значений для проверки.
И наконец, для построения красивой таблицы свойств объекта необходимо добавить идентификаторы иконок и идентификаторы контролов.

Всё. на основе перечисленной метаинформации можно построить таблицу свойств для любого объекта из модели.
Также на основе неё, можно построить тулбары и меню.

Результат просто потрясающий. то, что написано для одного базового класса работает для объектов всех классов.
Если классов 100, то объём работ сокращается в 100 раз. В 100 раз меньше кода, в 100 раз меньше мест для ошибок.
Вся метаинформация аккуратно и компактно лежит в одном месте.


Что вы об этом думаете? Меня интересуют критические замечания об этом подходе как теоритического так и практического характера.

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

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

C>То, что вы описали является любимым мифом разработчиков. Результат, который вы получите иначе как браузером базы данных назвать нельзя -- на выходе бедному пользователю придется работать с моделью реализации системы. С такой моделью работать может только робот с бесконечной памятью и безграничным вниманием. Интерфейсы нужно проектировать исходя из слабостей Homo Sapiens и опираясь на его сильные стороны. Так как работающей модели Homo Sapiens до сих пор нет, то и о генерации интерфейса речь идти не может.

Очень смешно.
Но я считаю, что вы заблуждаетесь.

Потому, что пользовательский интерфейс всё равно генерится на основе той-же информации только расположенной в ресурсах и размазанной по коду. Вопрос просто в удобном представлении этой информации.

Должнобыть словосочетание генерация интерфейса подействавала на вас как красная тряпка на быка. И Вы даже не стали углубляться в суть проблемы. Покрайней мере вы точно не стали ставить себя на место разработчика, перед которым стоит задача реализации иерархии из сотни интерфейсов, к которой добавляется иерархия откатов и иерархия классов GUI-обьектов, и не одна. Должно быть вы считаете разработчика роботом способным сознательно взяться за программирование такого хаоса по старинке.

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

C>То, что вы описали является любимым мифом разработчиков. Результат, который вы получите иначе как браузером базы данных назвать нельзя -- на выходе бедному пользователю придется работать с моделью реализации системы. С такой моделью работать может только робот с бесконечной памятью и безграничным вниманием. Интерфейсы нужно проектировать исходя из слабостей Homo Sapiens и опираясь на его сильные стороны. Так как работающей модели Homo Sapiens до сих пор нет, то и о генерации интерфейса речь идти не может.

Позвольте не согласиться. Если формы жесткие, то это может быть иногда правда. Правда почему-то мы все, тем не менее, легко пользуемся ПропертиГридом в студии, который к тому же до безобразия простой, но ничего. В SQL2005 тоже почему-то тот-же простенький контрол решает задачи форм.

Но тем не менее — есть вариант. Создаете интерфейс диалогов на основе атрибутов, а потом позволяете пользователю/администратору настроить диалоги (причем 1 класс может ведь иметь разные диалоги) под себя/пользователей.



Конечно, основное окно так построить нельзя — у него задача не редактировать объекты, а объединять все вместе, но диалоги так можно строить вполне — не трогая код вообще.



А еще можно взять кодогенератор и не пользоваться рефлекшеном — это даст и скорость и гибкость...

Вот теперь скажите, что думаете...

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

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

пару проблем, которые сразу вылазят для таких интерфейсов:
— ориентированность только на работу с данными (что делает задачу построения интерфейсов в некоторых случаях сложной, для примера можно взять Photoshop или Ms Word интерфейсы... приходится подгонять все под одну абстракцию, что мешает делать интефейс ориентированные на обработку стримов данных, а не баз данных)
— юзабилити у таких интерфейсов достаточно низкий (для примера: шорткаты, таб ордеры, expandding|collapsing options или advanced|expert view, группировки данных)
— ориентированность только на стандартный набор контролов и типов данных (иначе надо придумывать механизми расшерения на разные типы данных)
— связку бизнесс логикой?! изминение данных одной проперти приводит к пересчету других пропертей, может даже изминение типов и котнтролов, которыми должны данные отображаться...

для простых случаев такой интерфейс может подойти. достаточно легко будет делать шаблоны, но от необходимости расширять все-равно ни куда не денешься... потому можно это просто рассмотреть как тулзу построения шаблона/скелета программы.
как законченное целое сделать framework явно будет трудно...

PS> сорри за ошибки в тексте, не селен компилятора нету...

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

A>пару проблем, которые сразу вылазят для таких интерфейсов:
A>- ориентированность только на работу с данными (что делает задачу построения интерфейсов в некоторых случаях сложной, для примера можно взять Photoshop или Ms Word интерфейсы... приходится подгонять все под одну абстракцию, что мешает делать интефейс ориентированные на обработку стримов данных, а не баз данных)

Вы меня не так поняли. Я же говорил — основные окна так делать скорее нельзя. Да и контролы иногда придется делать свои.
Но так и что-же вы хотите — речь же не шла о том, что вообще весь GUI делать атрибутами. Так конечно не бывает...
Но в целом я не согласен, поскольку не понимаю разницы между свойствами потока и базы. Речь шла о том, что есть куча объектов и их надо редактировать. Ну так вот хорошее решение. Чем плохо?

A>- юзабилити у таких интерфейсов достаточно низкий (для примера: шорткаты, таб ордеры, expandding|collapsing options или advanced|expert view, группировки данных)

Вы наверное плохо посмотрели картинку... Там и шорткаты, там и Expand-Collapse, там и группы и автоматические таб ордеры (а не те, которые вечно забывают поправить). Короче присмотритесь Юзабилити там цветет и пахнет с еще большей силой.

A>- ориентированность только на стандартный набор контролов и типов данных (иначе надо придумывать механизми расшерения на разные типы данных)

О нет — это конечно неправда. И набор контролов там существенно выше стандартного (калькуляторы как средство ввода чисел или гриды-деревья для выбора объектов) и, конечно, механизм расширения там красиво и элегантно сделан. ООП как никак.

A>- связку бизнесс логикой?! изминение данных одной проперти приводит к пересчету других пропертей, может даже изминение типов и котнтролов, которыми должны данные отображаться...

1. Нет проблем учитывать бизнес-логику — изменили "пропертю" — "отрейзили" "ивент".
2. Могу вам сказать так — есть гайд, например, от Майкрософт — проперти должны быть независимы. По возможности.
Почему? Потому что программист никогда не ждет, что установка пропертей в разном порядке меняет результат. Иногда это увы не так — Min/Max/Value тому пример. Ну это исключение. И то это исключение приводит регулярно к багам. А вот вызов методов — это другое дело, это не свойство. Но скажу по секрету, ведь вызов метода — это новый диалог, а его можно строить точно по тем же принципам, что и диалог объекта .

A>для простых случаев такой интерфейс может подойти. достаточно легко будет делать шаблоны, но от необходимости расширять все-равно ни куда не денешься... потому можно это просто рассмотреть как тулзу построения шаблона/скелета программы.
A>как законченное целое сделать framework явно будет трудно...

Короче не согласен. Рекомендую изучить вопрос — откроете много нового (может сэкономите себе полжизни .

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

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

... skipped ...

в целом я согласен, что на картинках все выглядит прилично на сколько легко это будет заюзать для чего-то реального?! тут надо писать прогу и смотреть.. или если есть описание use-case'ов для этой системы...

stream ориентированные интерфейсы, это когда у тебя нет жесткой структуры данных, а есть последовательно команд/структур/описателей, которые формируют поведение программы и ее логики, но при этом нету постояннства и фиксированной БД. (актуально для систем аля риал-тайм или обработки/опроса хардварных датчиков и т.п.)

A>>- ориентированность только на стандартный набор контролов и типов данных (иначе надо придумывать механизми расшерения на разные типы данных)

MS>О нет — это конечно неправда. И набор контролов там существенно выше стандартного (калькуляторы как средство ввода чисел или гриды-деревья для выбора объектов) и, конечно, механизм расширения там красиво и элегантно сделан. ООП как никак.

давай возьмем простой пример:
— я хочу вставить Gant Chart от сторонего разработчика
— я хочу сделать custom context menu для поля/контрола

все равно столкнешься с ситуацие недостатка существующих контролов или необходимости расширять их логику...

A>>- связку бизнесс логикой?! изминение данных одной проперти приводит к пересчету других пропертей, может даже изминение типов и котнтролов, которыми должны данные отображаться...

MS>1. Нет проблем учитывать бизнес-логику — изменили "пропертю" — "отрейзили" "ивент".
MS>2. Могу вам сказать так — есть гайд, например, от Майкрософт — проперти должны быть независимы. По возможности.

это все гут и гайд я тоже читал... но если пропертя — это конфинурация контрола под какую-то логику?! самы простой пример: визуальный стиль контрола, меняет сразу много пропертей?! также есть тенденция отказа от диалогового стиля в программах. подавай докинг-панели и т.п. новшества... все-это так или иначе влияет на формирование GUI.

MS>Короче не согласен. Рекомендую изучить вопрос — откроете много нового (может сэкономите себе полжизни .

рекомендую изучить вопрос на примере Delphi, аналогчные разработки существуют под него, но супер популярности они не получили. интересно почему?! потому что очень тяжело кастомизировать и цена кусучая... на .NET это стало чуть проще, но жизнь от этого супер не стала...

---
В целом я прихожу к мнению, что это вопрос из разряда "филосовских войн", кто-то предпочитает писать все по отдельности... предложенное тобой вариант построения ни чем сильно не отличается от усовершенствованого варианта Rapid Development тулзы, того же IDE студии, только с записью натсроек не в отдельных фалах-формах, а в виде методанных на уровне бизнесс логики...

при таком подходе нельзя будет построить распределенной системы, где бизнесс леер работает на отдельном компе и доступ к нему осуществляется по remouting технологии. Для случая когда все леера собраны в одном флаконе, такое работать будет...

хотя обходной пусть всегда можно найти...

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

A>в целом я согласен, что на картинках все выглядит прилично на сколько легко это будет заюзать для чего-то реального?! тут надо писать прогу и смотреть.. или если есть описание use-case'ов для этой системы...

Проверено на реальном — от сердца идеи отрываю

A>stream ориентированные интерфейсы, это когда у тебя нет жесткой структуры данных, а есть последовательно команд/структур/описателей, которые формируют поведение программы и ее логики, но при этом нету постояннства и фиксированной БД. (актуально для систем аля риал-тайм или обработки/опроса хардварных датчиков и т.п.)

Это же не имеет значение. Я разницы не улавливаю — это тоже можно так делать... Конечно не все. Но диалоги то у вас остаются. Да и вообще человек не об этом спрашивал...

A>давай возьмем простой пример:
A>- я хочу вставить Gant Chart от сторонего разработчика
Да, в самую точку — я делаю свой Гант Чарт. Самый ядреный.
И, конечно, вставить его проблем никаких... Компонентная модель.

A>- я хочу сделать custom context menu для поля/контрола
Не вопрос — вот вам событие (и еще куча на все случаи жизни).

A>все равно столкнешься с ситуацие недостатка существующих контролов или необходимости расширять их логику...
А в чем проблема расширения ее логики? Да это не проблема — расширяй логику, так и надо.

A>это все гут и гайд я тоже читал... но если пропертя — это конфинурация контрола под какую-то логику?! самы простой пример: визуальный стиль контрола, меняет сразу много пропертей?! также есть тенденция отказа от диалогового стиля в программах. подавай докинг-панели и т.п. новшества... все-это так или иначе влияет на формирование GUI.

Требуется расшифровка. Я, честно говоря не смог вникнуть. Докинг панели? новшевства? Чему это противоречит.
Тема — есть много объектов, надо диалоги для них — я предложил решение...

MS>>Короче не согласен. Рекомендую изучить вопрос — откроете много нового (может сэкономите себе полжизни .

A>рекомендую изучить вопрос на примере Delphi, аналогчные разработки существуют под него, но супер популярности они не получили. интересно почему?! потому что очень тяжело кастомизировать и цена кусучая... на .NET это стало чуть проще, но жизнь от этого супер не стала...

Да видел я все это на дельфях уж много раз. И там это вполне работало. А сейчас прогресс, опыт.
Стало лучше. Жизнь не стала супер, просто диалоги можно тоннами больше не клепать. Других дел тоже много.

A>---
A>В целом я прихожу к мнению, что это вопрос из разряда "филосовских войн", кто-то предпочитает писать все по отдельности... предложенное тобой вариант построения ни чем сильно не отличается от усовершенствованого варианта Rapid Development тулзы, того же IDE студии, только с записью натсроек не в отдельных фалах-формах, а в виде методанных на уровне бизнесс логики...

Ну, я как раз предостерегал от философских войн...
IDE студии это компайл-тайм. К тому же он реально неудобен для людей.

A>при таком подходе нельзя будет построить распределенной системы, где бизнесс леер работает на отдельном компе и доступ к нему осуществляется по remouting технологии. Для случая когда все леера собраны в одном флаконе, такое работать будет...

Еще как будет работать. Я даже не буду спрашивать, откуда такие мысли — на лицо скороспелая мысль.

A>хотя обходной пусть всегда можно найти...

У нас работает. И система так распределена, что дай Бог другим так
Короче кому-то не пригодится, а кто-то будет рад совету.

Согласен.
Что скажите по поводу моего-то предложения

Автор: Max.Subpixel
Дата: 11.04.06

?

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

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

скажи лучше где это "чудо" взять можно и попробовать?! тогда смогу более конкретно сказть в чем проблемы есть... попробую на наши проекты "натянуть"...

если идея вынашивается долго, то думаю, что большинство проблем тогда устранено...

смущает только свой набор контролов... на сколько он свой? т.е. можно ли легко перейти от стандартных написанных диалогов на подход от твоего фреймворка?!...

миграция тут важный вопрос.

еще вопрос "легко-вестность" такого подхода?! в каких случаях его оправдано юзать?!

если взять предпосылки выложенные из первого поста, то подход "реально" оправданный...

PS> sorry какого-то авторизация на rsdn отвалилась...

Здравствуйте, WoldemaR, Вы писали:
WR>Потому, что пользовательский интерфейс всё равно генерится на основе той-же информации только расположенной в ресурсах и размазанной по коду. Вопрос просто в удобном представлении этой информации.
Нет. Нормальный пользовательский интерфейс генерится руками, на основе здравого смысла и юзабилити-тестов. И он очень редко похож на структуру классов данных или что-то в этом роде. ПропертиГрид приемлем только для программистов.

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

А>скажи лучше где это "чудо" взять можно и попробовать?! тогда смогу более конкретно сказть в чем проблемы есть... попробую на наши проекты "натянуть"...

www.devexpress.com

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

Изучите. Там свои контролы, но можно дописывать свои или вставлять чужие. У нас некоторые свои.
Контролы покрывают все стандартные плюс еще куча.



А>миграция тут важный вопрос.
А>еще вопрос "легко-вестность" такого подхода?! в каких случаях его оправдано юзать?!

У нас есть очень сложные формы — проблем никаких. Вы все равно пишете некий свой слой, который работает с диалогами.
Но кодогенерация все это дело превращает в сложность O(1). У них нет собственно привязки к атрибутам, но дописав чуть своего вы получите то, что вам надо и так как надо очень малой кровью.

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

MS>Согласен.
MS>Что скажите по поводу моего-то предложения

Автор: Max.Subpixel
Дата: 11.04.06

?

Всё это очень интересно.

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

Теперь о деле.

Возможно, что я смогу взять на себя treectrl и gridctrl на основе .NET.
Надо только согласовать иерархию используемых для этого атрибутов.

Я ещё колеблюсь в выборе между C# и MC++. Неопределился. Но склоняюсь к C#. Так чтоб уж сразу избавиться от иллюзий применения небезопасного кода. А вы что используете ?

Есть ещё одно замечание.
некоторые генераторы документации используют XML внутри комментариев. И это есть некоторая альтернатива существующей реализации атрибутов. Не на это ли вы намекали? Может есть уже готовые решения и альтернатива reflection.net как самостоятельное расширение языка?

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

S>Здравствуйте, WoldemaR, Вы писали:
WR>>Потому, что пользовательский интерфейс всё равно генерится на основе той-же информации только расположенной в ресурсах и размазанной по коду. Вопрос просто в удобном представлении этой информации.
S>Нет. Нормальный пользовательский интерфейс генерится руками, на основе здравого смысла и юзабилити-тестов. И он очень редко похож на структуру классов данных или что-то в этом роде. ПропертиГрид приемлем только для программистов.

Я очень цень Ваше мнение. Благодарю Вас за то, что Вы нашли время его высказать.

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

WR>Возможно, что я смогу взять на себя treectrl и gridctrl на основе .NET.
WR>Надо только согласовать иерархию используемых для этого атрибутов.

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

WR>Я ещё колеблюсь в выборе между C# и MC++. Неопределился. Но склоняюсь к C#. Так чтоб уж сразу избавиться от иллюзий применения небезопасного кода. А вы что используете ?

C#. Это более удобно в .NET, а недостатков по сравнению с MC++ в бизнес приложениях нет (мы не нашли по крайней мере).

WR>Есть ещё одно замечание. некоторые генераторы документации используют XML внутри комментариев. И это есть некоторая альтернатива существующей реализации атрибутов. Не на это ли вы намекали? Может есть уже готовые решения и альтернатива reflection.net как самостоятельное расширение языка?

Я таких не знаю, да и особой нужды не вижу. Компилятор просто знает что делать с этими XML тэгами, но это не альтернатива атрибутам и не надстройка языка. Атрибуты все-равно нужны. Хотя бы что-бы написать по месту дефолтное нормальное имя свойства или метода. Мы еще используем дополнительный способ получать это нормальное имя, описание, безопасность, условия выборки объектов и т.д., поскольку нам надо иметь многоязычность и возможность конфигурирования в рантайме. Но если конфигурации нет или добавилось новое свойство еще не описанное, то мы хоть как-то сможет его показать.

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

S>Здравствуйте, WoldemaR, Вы писали:
WR>>Потому, что пользовательский интерфейс всё равно генерится на основе той-же информации только расположенной в ресурсах и размазанной по коду. Вопрос просто в удобном представлении этой информации.
S>Нет. Нормальный пользовательский интерфейс генерится руками, на основе здравого смысла и юзабилити-тестов. И он очень редко похож на структуру классов данных или что-то в этом роде. ПропертиГрид приемлем только для программистов.

Я согласен про ПропертиГрид — он годится для программистов и администраторов.
Но я предлагал нечто другое — там вам пожалуйста — полная свобода.

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

WR>Здравствуйте, Max.Subpixel, Вы писали:

WR>Теперь о деле.

WR>Возможно, что я смогу взять на себя treectrl и gridctrl на основе .NET.
WR>Надо только согласовать иерархию используемых для этого атрибутов.

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

Здравствуйте, Аноним, Вы писали:

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

А>>скажи лучше где это "чудо" взять можно и попробовать?! тогда смогу более конкретно сказть в чем проблемы есть... попробую на наши проекты "натянуть"...

А>www.devexpress.com

МОЕ ФЕ:
тут проблемы с перформансом... (парвда не знаю как в последних версиях, пробовали их где-то год назад для одного проекта)
не расширяемые контролы, местами очень идиотски написанные вещи, так что не возможно обойти...

либу брали с сорсами, посмотрел на сорсы остался не в восторге... код очень мало похож на "безопасный" код, вернее совсем не похож... документированность кода слабая... намучался пока пересобрал либу, правда почему-то пару кусков сорсов не хватило, пришлось выкачивать через p2p... спасибо Resharper — спас от переформатирования кода и помог жить дальше...

Сапорт ихний убил наповал, так нам и не смогли помочь. Ответили мол не предусмотренно архитектурой контрола... легковесными эти контролы назвать тяжело.

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

A>могу предложить TreeListView собственной закваски...
A>правда в не доработаном варианте, но достаточно рабочий чтобы показывать и дописываться...

Не хочу вам портить продажи , но взгляните на предложение от devExpress



Он уже кстати рабочий.

Расскажите про свой, что там.

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

A>МОЕ ФЕ:
A>тут проблемы с перформансом... (парвда не знаю как в последних версиях, пробовали их где-то год назад для одного проекта)
A>не расширяемые контролы, местами очень идиотски написанные вещи, так что не возможно обойти...

Почему-то у нас нет проблем с перформансом, может правда что-то изменилось.
Не расширяемые контролы? Например? Я пока с этим не столкнулся.

A>либу брали с сорсами, посмотрел на сорсы остался не в восторге... код очень мало похож на "безопасный" код, вернее совсем не похож... документированность кода слабая... намучался пока пересобрал либу, правда почему-то пару кусков сорсов не хватило, пришлось выкачивать через p2p... спасибо Resharper — спас от переформатирования кода и помог жить дальше...

Что такое безопасный код?
Исходный код я не смотрел, как-то нужды не было...

A>Сапорт ихний убил наповал, так нам и не смогли помочь. Ответили мол не предусмотренно архитектурой контрола... легковесными эти контролы назвать тяжело.

Процитируйте проблему. Но конечно, на что-то возможно это не рассчитано.
Мне трудно представить, правда, что тогда рассчитано...
Что такое легковесные — это видимо и не контролы тогда совсем...
Может быть дело было в неправильном использовании? Пример, приведите, мне интересно.