Итак. Есть объектная модель, состоящая из сотни классов в которых присутствуют свойства и методы. Задача. Надо отображать и редактировать объекты этой модели.
Строим универсальный браузер. Используем 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, Вы писали:
MS>Здравствуйте, alku, Вы писали:
скажи лучше где это "чудо" взять можно и попробовать?! тогда смогу более конкретно сказть в чем проблемы есть... попробую на наши проекты "натянуть"...
если идея вынашивается долго, то думаю, что большинство проблем тогда устранено...
смущает только свой набор контролов... на сколько он свой? т.е. можно ли легко перейти от стандартных написанных диалогов на подход от твоего фреймворка?!...
миграция тут важный вопрос.
еще вопрос "легко-вестность" такого подхода?! в каких случаях его оправдано юзать?!
если взять предпосылки выложенные из первого поста, то подход "реально" оправданный...
PS> sorry какого-то авторизация на rsdn отвалилась...
Здравствуйте, WoldemaR, Вы писали: WR>Потому, что пользовательский интерфейс всё равно генерится на основе той-же информации только расположенной в ресурсах и размазанной по коду. Вопрос просто в удобном представлении этой информации.
Нет. Нормальный пользовательский интерфейс генерится руками, на основе здравого смысла и юзабилити-тестов. И он очень редко похож на структуру классов данных или что-то в этом роде. ПропертиГрид приемлем только для программистов.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[8]: Генерация GUI на основе атрибутов
От:
Аноним
Дата:
11.04.06 13:09
Оценка:
Здравствуйте, alku, Вы писали:
А>скажи лучше где это "чудо" взять можно и попробовать?! тогда смогу более конкретно сказть в чем проблемы есть... попробую на наши проекты "натянуть"...
www.devexpress.com
А>если идея вынашивается долго, то думаю, что большинство проблем тогда устранено... А>смущает только свой набор контролов... на сколько он свой? т.е. можно ли легко перейти от стандартных написанных диалогов на подход от твоего фреймворка?!...
Изучите. Там свои контролы, но можно дописывать свои или вставлять чужие. У нас некоторые свои.
Контролы покрывают все стандартные плюс еще куча.
А>миграция тут важный вопрос. А>еще вопрос "легко-вестность" такого подхода?! в каких случаях его оправдано юзать?!
У нас есть очень сложные формы — проблем никаких. Вы все равно пишете некий свой слой, который работает с диалогами.
Но кодогенерация все это дело превращает в сложность O(1). У них нет собственно привязки к атрибутам, но дописав чуть своего вы получите то, что вам надо и так как надо очень малой кровью.
У меня есть одно (но не единственное ) нехорошее свойство. Я люблю перепрыгивать через промежуточные этапы логических выкладок при изложении мыслей. Поэтому меня часто непонимают, а ещё чаще понимают неправильно. Как мне показалось вы тоже обладаете такой склонностью, безусловно компенсирующей другие достоинства. Поэтому мы кажется друг друга поняли. По крайней мере насчёт концепта.
Теперь о деле.
Возможно, что я смогу взять на себя treectrl и gridctrl на основе .NET.
Надо только согласовать иерархию используемых для этого атрибутов.
Я ещё колеблюсь в выборе между C# и MC++. Неопределился. Но склоняюсь к C#. Так чтоб уж сразу избавиться от иллюзий применения небезопасного кода. А вы что используете ?
Есть ещё одно замечание.
некоторые генераторы документации используют XML внутри комментариев. И это есть некоторая альтернатива существующей реализации атрибутов. Не на это ли вы намекали? Может есть уже готовые решения и альтернатива reflection.net как самостоятельное расширение языка?
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, WoldemaR, Вы писали: WR>>Потому, что пользовательский интерфейс всё равно генерится на основе той-же информации только расположенной в ресурсах и размазанной по коду. Вопрос просто в удобном представлении этой информации. S>Нет. Нормальный пользовательский интерфейс генерится руками, на основе здравого смысла и юзабилити-тестов. И он очень редко похож на структуру классов данных или что-то в этом роде. ПропертиГрид приемлем только для программистов.
Я очень цень Ваше мнение. Благодарю Вас за то, что Вы нашли время его высказать.
Re[5]: Генерация GUI на основе атрибутов
От:
Аноним
Дата:
11.04.06 13:25
Оценка:
Здравствуйте, 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>Сапорт ихний убил наповал, так нам и не смогли помочь. Ответили мол не предусмотренно архитектурой контрола... легковесными эти контролы назвать тяжело.
Процитируйте проблему. Но конечно, на что-то возможно это не рассчитано.
Мне трудно представить, правда, что тогда рассчитано...
Что такое легковесные — это видимо и не контролы тогда совсем...
Может быть дело было в неправильном использовании? Пример, приведите, мне интересно.
Здравствуйте, Max.Subpixel, Вы писали:
MS>Я согласен про ПропертиГрид — он годится для программистов и администраторов. MS>Но я предлагал нечто другое — там вам пожалуйста — полная свобода.
То, что вы предлагаете, конечно же, намного лучше, чем проперти грид. Но все равно, непонятно, почему нужно заставлять пользователей перекладывать контролы. Если предметная область хорошо определена, то существует относительно немного оптимальных структур UI; и выбрать их — обязанность проектировщика. Кто-то из usability спецов говорил, что все настройки UI в программах отражают непонимание разработчиками стоящей перед ними задачи.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Аноним, Вы писали:
А>Подумайте о кодогенерации... Атрибуты это не отменяет, зато позволяет какие-то вещи делать быстрее (производительность и время на разработку). По сути R# полезная и удобная вещь — парсер есть, кодогенератор есть. Если не обращать внимание на мелочи в орфографии — все работает. Спасибо Владу (он меня уже не любит, правда, за флейм о шрифтах )
Да. это интересная мысль. вот только мне кажется я ещё не дорос до неё. Я ещё не наигрался с объектной моделью в стиле C#.
Кстати, как мне кажется, каждому программеру надо наиграться с некоторой технологией прежде чем перейти на следующий уровень. Как например, сторонники кустарного GUI ещё не устали от игры в формочки-кнопочки.
Наверное поэтому мы так медленно двигаемся в направлении продвинутых парадигм программирования типа Lisp-a.
А>C#. Это более удобно в .NET, а недостатков по сравнению с MC++ в бизнес приложениях нет (мы не нашли по крайней мере).
А можно вопрос?. (блин!, опять тавтология) Так вот вопрос — у вас изменения в объектах модели синхронизируются между клиентскими приложениями? если да, то не могли бы вы рассказать как это у вас работает.
Здравствуйте, alku, Вы писали:
A>могу предложить TreeListView собственной закваски... A>правда в не доработаном варианте, но достаточно рабочий чтобы показывать и дописываться...
спасибо. всё лучше чем с чистого листа начинать
пиши на vladimir_lipatov@mail.ru
Здравствуйте, WoldemaR, Вы писали:
WR>Да. это интересная мысль. вот только мне кажется я ещё не дорос до неё. Я ещё не наигрался с объектной моделью в стиле C#.
Воспринимайте её как некий простой код, который делает за вас тупую работу по программированию — позволяет избежать ошибки и делать то, что вам уже надоело, позволяя не придумывать гигантских и ненужных конструкций.
WR>Кстати, как мне кажется, каждому программеру надо наиграться с некоторой технологией прежде чем перейти на следующий уровень. Как например, сторонники кустарного GUI ещё не устали от игры в формочки-кнопочки. WR>Наверное поэтому мы так медленно двигаемся в направлении продвинутых парадигм программирования типа Lisp-a.
Наверное это правильно. Но некоторые вещи реально экономят время.
А играть с технологией мне кажется нужно не до предела — я этим сам часто страдал...
WR>А можно вопрос?. (блин!, опять тавтология) Так вот вопрос — у вас изменения в объектах модели синхронизируются между клиентскими приложениями? если да, то не могли бы вы рассказать как это у вас работает.
Во-первых у нас .NET — не знаю, что у вас.
У нас сделано так — мы взвесили все за и против и классифицировали изменения:
1. Частые в райнтайме
Это мы делаем без изменения самих объектов — т.е. коллекции на объектах (коллекция данных + коллекция правил работы с ними). 2. Редкие в рантайме
Это мы делаем как DynamicMethod — т.е. подцепка свойств объектам путем доставки динамических методов в данных объекта, описывающего класс. Позволяет работать без всяких там псевдо-имен классов (как в ASP.NET) и без работы с выгрузкой доменов. 3. Редкие в компайл-тайме
Это требует рестарта при получении объекта с измененной схемой. После рестарта грузятся новые классы и схема кэшированных данных обновляется.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Max.Subpixel, Вы писали:
MS>>Я согласен про ПропертиГрид — он годится для программистов и администраторов. MS>>Но я предлагал нечто другое — там вам пожалуйста — полная свобода. S>То, что вы предлагаете, конечно же, намного лучше, чем проперти грид. Но все равно, непонятно, почему нужно заставлять пользователей перекладывать контролы. Если предметная область хорошо определена, то существует относительно немного оптимальных структур UI; и выбрать их — обязанность проектировщика. Кто-то из usability спецов говорил, что все настройки UI в программах отражают непонимание разработчиками стоящей перед ними задачи.
Тут вопрос о применениях. Конечный пользователь не будет настраивать диалоги — он даже тулбары то не настраивает...
Поэтому речь не об этом. Я и, по всей видимости, Вольдемар, связаны с крупными системами. А здесь работают другие принципы — классы все время меняются — от клиента к клиенту, от задачи к задаче. И настройкой диалога должны заниматься те, кто, например, готовит продукт под конкретного клиента, или делает специальную версию, или администратор клиента. А в целом я согласен с тем, что вы говорите — вопрос лишь в том, что это не всегда возможно. И те кто настраивают диалоги, наверное, должны и анализировать и исследования проводить и т.д. Но это не программисты. 100%. А так — сделал продукт, отдал юзабелисту, а он сидит и формы компонует. Тут сразу ему и тесты готовы и прототипов не надо. Понимаете? Мне кажется это только всем на пользу...
Здравствуйте, Max.Subpixel, Вы писали:
MS>Здравствуйте, alku, Вы писали:
MS>Процитируйте проблему. Но конечно, на что-то возможно это не рассчитано. MS>Мне трудно представить, правда, что тогда рассчитано... MS>Что такое легковесные — это видимо и не контролы тогда совсем... MS>Может быть дело было в неправильном использовании? Пример, приведите, мне интересно.
сорри тяжело вспомнить, и фирму поменял и проект... постараюсь на досуге найти...
Здравствуйте, Max.Subpixel, Вы писали:
MS>Во-первых у нас .NET — не знаю, что у вас. MS>У нас сделано так — мы взвесили все за и против и классифицировали изменения:
Надеюсь, что у нас тоже будет NET, поэтому собираю аргументы за и против.
MS>1. Частые в райнтайме MS>Это мы делаем без изменения самих объектов — т.е. коллекции на объектах (коллекция данных + коллекция правил работы с ними).
У нас такие изменения относятся к работе скрипта.
Идея такая. при модификации объекта никакой синхронизации с сервером и опосредованно с другими приложениями не происходит, но формируется список изменённых объектов. Затем над этим списком делаем Commit. Обекты серилизуются бинарно и передаются на сервер. Сервер раздаёт уведомления остальным клиентам и пишет в базу.
пока ещё не придумал как соединить клиент с сервером приложений. пока рассматриваю 2 варианта .NET Remouting и http://www.genuinechannels.com
MS>2. Редкие в рантайме MS>Это мы делаем как DynamicMethod — т.е. подцепка свойств объектам путем доставки динамических методов в данных объекта, описывающего класс. Позволяет работать без всяких там псевдо-имен классов (как в ASP.NET) и без работы с выгрузкой доменов.
Это как правило ручные модификации через пользовательский интерфейс.
Тут нам нужена синхронизация в отдельности для каждого свойства/метода и + валидация и возможность откатов. т.е. придётся формировать стеки команд.
MS>3. Редкие в компайл-тайме MS>Это требует рестарта при получении объекта с измененной схемой. После рестарта грузятся новые классы и схема кэшированных данных обновляется.
Только не в компайл тайме. Но очень похожие изменения происходят при:
1) Обновлении объектов клиента после получения уведомления со списком изменённых объектов от сервера.
2) Восстановлении конфигурации прерванной сессии.
В общем получается, что объектная модель представляет из себя иерархию классов с довольно хитрой, но примерно одинаковой реализацией методов set для каждого свойства и add/remove для контейнеров.
Кстати насчёт remove. Этот метод потенциально может нарушить целостность базы. Решили, что выполнять его может только админ в монопольном режиме. в парадигме COM надо было-бы реализовывать и запрашивать специальный интерфейс администратора. У нас появилась другая идея. — Помечать такие админские методы атрибутом forAdminOnlyAttribute и при генерации GUI выдавать их на тулбар или не выдавать в зависимости от прав пользователя.
Здравствуйте, alku, Вы писали:
A>сорри тяжело вспомнить, и фирму поменял и проект... постараюсь на досуге найти...
Может это был глюк?
Или что-то там такое плохо работало, но исправили.
Или было что-то совсем редкое?
Или надо было как-то архитектурно вопрос решать.
Я рассматривал разные компоненты — не могу сказать, что DX компоненты тормозят.
Они вполне адекватно работают. Глупостей я тоже пока не видел, по крайней мере, существенных.
Но, поймите меня правильно, я не работаю на DX и опыт эксплуатации еще не огромен, так что а) я могу что-то не знать (потому и спрашиваю) б) мне пока нравится больше чем то, что пока видел другое. Но и, конечно, не бывает решений, которые устроят всех. Просто я не согласен, что там качество плохое. Уж точно лучше самоделок и других известных наборов.
Best Regards. Max.
Re[12]: Генерация GUI на основе атрибутов
От:
Аноним
Дата:
11.04.06 16:48
Оценка:
Здравствуйте, alku, Вы писали:
A>есть такая книжка "Безопасный код" Microsoft press — очень советую почитать... highly recommended.
Здравствуйте, WoldemaR, Вы писали:
WR>Надеюсь, что у нас тоже будет NET, поэтому собираю аргументы за и против.
А, да, я забыл.
MS>>1. Частые в райнтайме MS>>Это мы делаем без изменения самих объектов — т.е. коллекции на объектах (коллекция данных + коллекция правил работы с ними).
WR>У нас такие изменения относятся к работе скрипта. WR>Идея такая. при модификации объекта никакой синхронизации с сервером и опосредованно с другими приложениями не происходит, но формируется список изменённых объектов. Затем над этим списком делаем Commit. Обекты серилизуются бинарно и передаются на сервер. Сервер раздаёт уведомления остальным клиентам и пишет в базу. WR>пока ещё не придумал как соединить клиент с сервером приложений. пока рассматриваю 2 варианта .NET Remouting и http://www.genuinechannels.com
От ремотинга мы отказались после прошлой версии. Медленно и плохоконтроллируемо. Для кого-то наверное пойдет.
Но надо сказать мы вообще отказались от отправки изменений на сервер в виде объектов.
Вместо этого мы отправляем верхние вызовы методов (кодогенерация тут тоже).
Преимуществ просто масса. Если интересно — расскажу.
Но я говорил про изменения схемы, а не объектов...
MS>>2. Редкие в рантайме MS>>Это мы делаем как DynamicMethod — т.е. подцепка свойств объектам путем доставки динамических методов в данных объекта, описывающего класс. Позволяет работать без всяких там псевдо-имен классов (как в ASP.NET) и без работы с выгрузкой доменов.
WR>Это как правило ручные модификации через пользовательский интерфейс. WR>Тут нам нужена синхронизация в отдельности для каждого свойства/метода и + валидация и возможность откатов. т.е. придётся формировать стеки команд.
Да, стеки команд мы и посылаем. Сервер посылает объекты. Мы ему команды. База локальная дублирована. Онлайн/Оффлайн, откат итп.
MS>>3. Редкие в компайл-тайме MS>>Это требует рестарта при получении объекта с измененной схемой. После рестарта грузятся новые классы и схема кэшированных данных обновляется.
WR>Только не в компайл тайме. Но очень похожие изменения происходят при: WR>1) Обновлении объектов клиента после получения уведомления со списком изменённых объектов от сервера. WR>2) Восстановлении конфигурации прерванной сессии.
Опять же я говорил про смену классов. А не объектов.
WR>В общем получается, что объектная модель представляет из себя иерархию классов с довольно хитрой, но примерно одинаковой реализацией методов set для каждого свойства и add/remove для контейнеров.
Кодогенерация вас спасет. Иначе труба или читать IL в рантайме и проверять.
WR>Кстати насчёт remove. Этот метод потенциально может нарушить целостность базы. Решили, что выполнять его может только админ в монопольном режиме. в парадигме COM надо было-бы реализовывать и запрашивать специальный интерфейс администратора. У нас появилась другая идея. — Помечать такие админские методы атрибутом forAdminOnlyAttribute и при генерации GUI выдавать их на тулбар или не выдавать в зависимости от прав пользователя.
У нас круче. У нас вообще на все атрибуты ролей. А потом админ может переконфигурировать это под то, что ему надо. И + еще ресурсная безопасность сбоку. А за счет того, что мы не шлем объекты на сервер — кроме всех плюсов у нас еще и гарантия безопасности — метод присылается полностью подписанный сертификатом клиента. Может хоть по почте присылать обновления... А мержить как удобно...
MS>Позвольте не согласиться. Если формы жесткие, то это может быть иногда правда. Правда почему-то мы все, тем не менее, легко пользуемся ПропертиГридом в студии, который к тому же до безобразия простой, но ничего. В SQL2005 тоже почему-то тот-же простенький контрол решает задачи форм.
Ваша ошибка в том, что на взаимодействие пользователя с программой вы рассматриваете с точки зрения модели реализации, что в корне уже неправильно. Дело даже не в том, что есть экраны которые надо проектировать, а есть вспомогательные экраны, которые можно сгенерировать на основе некоей внутренней структуры данных. При грамотном проектировании может оказаться, что вообще эти вспомогательные экраны и не нужны -- модальные окна (да и не модальные) это лучший способ заставить пользователя выйти их контекста основной работы и заставлять его принимать решения, когда этого делать совершенно не нужно.
Сгенерированные интерфейсы совершенно не предусматривают массу реальных сценариев, по которым работают пользователи и уж тем более не учитывают контекста их работы. Даже если есть тщательно описанный Use Case работы оператора, то там, как правило, не учитывается как пользователь вводит информацию -- со слов клиента или например с листа бумаги.
Предсавьте себе, что реальные предметы герегировались бы исходя из внутренне структуры. Я думаю, что такой телевизор вы бы ни жизнь не купили У него была бы куча регуляторов, матрица совершенно одинаковых кнопок (на пульте в том числе), на диспелее была бы куча ненужно информации, и выглядел бы он так, что подходить к нему было бы страшно.
Кстати, искренне рекоммендую к прочтению пару книгу на эту тему:
"Психбольница в руках пациентов" Алана Купера, (http://www.bolero.ru/product-36418704.html?terms=%CD%EE%F0%EC%E0%ED
Здравствуйте, WoldemaR, Вы писали:
WR>Здравствуйте, copylove, Вы писали:
C>>То, что вы описали является любимым мифом разработчиков. Результат, который вы получите иначе как браузером базы данных назвать нельзя -- на выходе бедному пользователю придется работать с моделью реализации системы. С такой моделью работать может только робот с бесконечной памятью и безграничным вниманием. Интерфейсы нужно проектировать исходя из слабостей Homo Sapiens и опираясь на его сильные стороны. Так как работающей модели Homo Sapiens до сих пор нет, то и о генерации интерфейса речь идти не может.
WR>Очень смешно.
Зачем спрашивал-то? Чтобы нахамить всем, кто с тобой не согласен?
FYI, некто copylove, также известный как Алексей Копылов, сотрудник UIDesign Group (все это можно узнать из его профайла), и в русскоязычном юзабалити сообществе достаточно известный человек. К тому, что он утверждает, стоит хотя бы прислушаться.
Здравствуйте, copylove, Вы писали:
C>Ваша ошибка в том, что на взаимодействие пользователя с программой вы рассматриваете с точки зрения модели реализации, что в корне уже неправильно.
Вы меня неправильно поняли. Иногда бывают ситуации когда приходится идти с обеих сторон и искать компроммисы. Если у вас 2-3-10 форм и они жесткие, то полный порядок — делайте как всегда, это правильно и удобно.
C>Дело даже не в том, что есть экраны которые надо проектировать, а есть вспомогательные экраны, которые можно сгенерировать на основе некоей внутренней структуры данных.
Я с этим не спорю. Но иногда все — вы знаете — вот этим объектам нужны диалоги.
КОНЕЧНО там и вообще диалоги есть, просто так. Но речь не об этом.
C>При грамотном проектировании может оказаться, что вообще эти вспомогательные экраны и не нужны -- модальные окна (да и не модальные) это лучший способ заставить пользователя выйти их контекста основной работы и заставлять его принимать решения, когда этого делать совершенно не нужно.
Не очень понял суть в контексте темы.
C>Сгенерированные интерфейсы совершенно не предусматривают массу реальных сценариев, по которым работают пользователи и уж тем более не учитывают контекста их работы. Даже если есть тщательно описанный Use Case работы оператора, то там, как правило, не учитывается как пользователь вводит информацию -- со слов клиента или например с листа бумаги.
Вы просто не очень поняли что означает сгенерированные диалоги. Они могут быть абсолютно любыми... Но иногда уже очевидно — нужен диалог управления задачей. Там может еще 1001 способ управления задачей. Но еще и нужен диалог. И вот о таких диалогах идет речь. Немодальных.
C>Предсавьте себе, что реальные предметы герегировались бы исходя из внутренне структуры. Я думаю, что такой телевизор вы бы ни жизнь не купили У него была бы куча регуляторов, матрица совершенно одинаковых кнопок (на пульте в том числе), на диспелее была бы куча ненужно информации, и выглядел бы он так, что подходить к нему было бы страшно.
Это не совсем так (совсем не так):
1. Класс это не его внутренняя структура — это наоборот его фасад, на котором к тому же вы можете определить как он должен выглядеть
2. Вас никто не заставляет все ручки выносить наружу — вы выносите только те, которые нужны и в таком виде, как нужно (я больше скажу — вам в двух разных местах могут быть нужны 2 разных диалога на 1 и тот-же класс — пожалуйста
3. Выглядеть он будет так как вы хотите — практически никаких ограничений (вы видимо не читали, что я там бальше писал)
C>Кстати, искренне рекоммендую к прочтению пару книгу на эту тему: C>"Психбольница в руках пациентов" Алана Купера, (http://www.bolero.ru/product-36418704.html?terms=%CD%EE%F0%EC%E0%ED
Спасибо, как-нибудь, на досуге, но думаю, что я уже читал прилично переворачивающей литературы на эту тему и все стороны мозгов уже видел.
Поймите меня правильно. Я не спорю с вами — Вы все вроде как правильно говорите. Просто есть некоторые исключения (решения, которые, не такие как вы думаете/знаете). Потом есть особые ситуации. О них и была речь. Если внимательно прочитаете, то что я писал тут в теме, то скорее всего ваша претензия снимется. И добавлю, что я по професии юзабелист в первую очередь, а уже потом архитектор и менеджер продукта.
И кстати, знаете, довольно часто лучше бы программисты использовали уж ПропертиГрид, чем городили бы тот идиотизм, что они делают в интерфейсах...
И вообще, я к вам может еще прийду за консультациями (а то, что-то Ярослав Перевалов занят совсем), но буду пользоваться этими самыми диалогами. Так что не надо считать меня сторонником автоматических диалогов. Если задумаетесь, то поймете, то, что я предложил — это очень хороший вариант для юзабилити — он ничего общего не имеет с полным автоматом — это просто способ оторвать представление от логики и объектов. И способ создавать много диалогов без кода вообще и вообще после того, как приложение готово. Это же вообще мечта.
А книжки — почитаю на досуге, хотя Купера не люблю...
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>FYI, некто copylove, также известный как Алексей Копылов, сотрудник UIDesign Group (все это можно узнать из его профайла), и в русскоязычном юзабалити сообществе достаточно известный человек. К тому, что он утверждает, стоит хотя бы прислушаться.
Ну как-же, надо смотреть профиль всех кому собираешься "нахамить"? Это же так долго...
P.S. Я еще думаю, где-то я уже этот ник видел, но вроде не тут.
А тут вспомнил — ага, community.livejournal.com/ru_ucdesign
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>Здравствуйте, WoldemaR, Вы писали:
WR>>Здравствуйте, copylove, Вы писали:
C>>>То, что вы описали является любимым мифом разработчиков. Результат, который вы получите иначе как браузером базы данных назвать нельзя -- на выходе бедному пользователю придется работать с моделью реализации системы. С такой моделью работать может только робот с бесконечной памятью и безграничным вниманием. Интерфейсы нужно проектировать исходя из слабостей Homo Sapiens и опираясь на его сильные стороны. Так как работающей модели Homo Sapiens до сих пор нет, то и о генерации интерфейса речь идти не может.
WR>>Очень смешно.
ЗХ>Зачем спрашивал-то? Чтобы нахамить всем, кто с тобой не согласен? ЗХ>FYI, некто copylove, также известный как Алексей Копылов, сотрудник UIDesign Group (все это можно узнать из его профайла), и в русскоязычном юзабалити сообществе достаточно известный человек. К тому, что он утверждает, стоит хотя бы прислушаться.
Чувствую что стоит объясниться.
Так вот. Я вам как юзабелист юзабелисту объясню, что юзабилити юзабилити рознь. Есть разница между интерфейсом для бегинера и для эксперта. Эпловский стандарт по размещения элементов на формах десктопа пожно спустить в унитаз при проектировании вокзального терминала.
У нас этого юзабилити ну просто завались. ТОлько это, как правило, не примитивные формочки с кнопочками. А специализированные и очень дорогие контролы в которых отображаются карты, таблицы, диаграммы, графики, кореляционные разрезы. Всё это работает в обрамлении контрол-панелей. Которых нужно минимум, так как основная площадь занята спецконтролами, короче говоря это похоже на архитектуру CAD-систем. И универсальный браузер и универсальная таблица и проперти грид, очень нужны. Они тут рулят и спасают пользователя от хаотичного нагромождения модальных диалогов.
А рулят деревья, гриды т таблицы потому, что с системой работают не бегинеры и им важно быстро производить все изменения единым способом, не хлопая глазами вспоминая или узнавая расположение элементов на очень удобной уникальной форме. Ещё проблема в том, что таких форм — сотни. и если сядет бегинер их изучать, то с ним случиться перегрузка.
Появление каждой новой формы на экране — это задержка на её изучение, оно происходит медленнее изучения проперти грида, так как в гриде всё однотипно выровненно, а форма — это очередной полёт фантазии человека возомнившего себя юзабелистом.
Нет, я вовсе не против форм и юзабелистов.
Например, если надо продемонстрировать сложность системы и мотивировать клиентов на обучение, как это делается в ERP — системах, то конечно да. Там держать отдел специалистов по формочкам можно себе позволить.
Но у нас сейчас мескольно иная специфика работы.
Теперь по поводу моего хамства. Да, характер не сахар. Такая у меня реакция на неарументированные и безапеляционные утверждения отвергающего, неконструктивного характера.
Здравствуйте, copylove, Вы писали:
C>Ваша ошибка в том, что на взаимодействие пользователя с программой вы рассматриваете с точки зрения модели реализации, что в корне уже неправильно.
Не поймут вас. Поскольку мало кто умеет удерживать в голове два "мифа" одновременно.
(А "модель реализации" и "модель интерфейса" — это варианты мифов.)
А потому народ все равно будет либо показывать пользователю модель реализации,
либо прошивать в архитектуру системы жесткие завязки на пользовательский интерфейс.
Выше вы писали про "слабости Homo Sapiens" — пользовтаеля, но забываете про "слабости Homo Sapiens" — разработчика.
P.S.
Посмотрел ваш сайт.
Порадовался отсутвию "переливающихся рюшечек" в портфолио.
Огорчился отсутствию хотя бы некоего намека на прайс... Не могли бы вы исправить эту ситуацию,
скинув мне _порядок_ цен на alexsoff[собака]gmail.com ?
Здравствуйте, EXO, Вы писали:
EXO>Не поймут вас. Поскольку мало кто умеет удерживать в голове два "мифа" одновременно. EXO>(А "модель реализации" и "модель интерфейса" — это варианты мифов.) EXO>А потому народ все равно будет либо показывать пользователю модель реализации, EXO>либо прошивать в архитектуру системы жесткие завязки на пользовательский интерфейс.
Мне кажется, что вы слишком категоричны.
Так или иначе, но даже самые системные программисты, если им приходится делать интерфейс как-то, но думают. Другое дело, что 1) программисты не юзабелисты чаще всего (и не разбираются особо) 2) бывает конфликт задач и нельзя идеально сделать интерфейс, а уже потом плясать от него.
Здравствуйте, Max.Subpixel, Вы писали: MS>Мне кажется, что вы слишком категоричны.
Возможно.
Но жизнь, к сожалению, демонстирует примеры...
MS>Так или иначе, но даже самые системные программисты, если им приходится делать интерфейс как-то, но думают.
Конечно думают. Но думают как бы "со стороны"... "А вот для пользователя мы сделаем..."
То есть "для них", "внешнее". Мало кто дает себе труд залезть в чужую шкуру.
MS> 2) бывает конфликт задач и нельзя идеально сделать интерфейс, а уже потом плясать от него.
А это вообще никогда нельзя. Можно другое: изящно выразить одну модель на языке другой.
И это именно то решение. Поскольку порой у одной системы (у одной внутренней модели) бывает несколько совершенно разных (даже идеологически) внешних интефейса.
Для отображения объектной модели стандартными контролами, получается нетривиальное решение.
1) В одном случае надо брать имя для айтема дерева, из члена класса. Это когда класс представляет некоторые сущности посредством некоторых своих членов.
2) В другом случае надо брать имя айтема дерева из атрибута члена класса. Это когда класс представляет собой коллекцию сущностей.
Оба случая можно разрулить с помощью базового класса NamedObject и атрибутов.
но я сомневаюсь в ценности такого решения для более широкого применения.
Здравствуйте, Max.Subpixel, Вы писали:
MS>Но тем не менее — есть вариант. Создаете интерфейс диалогов на основе атрибутов, а потом позволяете пользователю/администратору настроить диалоги (причем 1 класс может ведь иметь разные диалоги) под себя/пользователей.
MS>А еще можно взять кодогенератор и не пользоваться рефлекшеном — это даст и скорость и гибкость...
MS>Вот теперь скажите, что думаете...
Прекрасный дизайнер форм. Только по моему мнению его должно дать в руки не пользователю/администртору, а разработчику UI.
Здравствуйте, Артур Станкевич, Вы писали:
АС>Прекрасный дизайнер форм. Только по моему мнению его должно дать в руки не пользователю/администртору, а разработчику UI.
Согласен. Просто администратору можно дать готовые на нем формы, чтобы он убрал то, что не используется в его компании, например...
На мой взгляд:
Идея data-driven UI хорошо, хотя бы потому, что существует немалое кол-во приложений
либо их фрагментов, где UI в большой степени отвечает структурам данных.
Таких приложений не большинство и речь идет не обязательно (повторюсь) обо всем приложении целиком,
а возможно о его фрагментах.
Если позволите, немного расскажу о нашем пути. Буду признателен за комментарии.
Мы выбрали неновый путь описания форм пользовательского интерфейса в XML-файлах.
Идея языка описания UI — простота (язык содержит необходимый минимум контролов и их свойств,
необходмых для создания форм, к слову, работаем на WinForms)
Генератор создает его дефолтный вариант по классам, после чего файлы UI можно
вручную (а, по хорошему, должно быть в визуальном редакторе) поредактировать.
Генератор создает не только единичные контрольки, но и контрольки, необходимые
для навигации между формами (отвечающие ссылкам и коллекциям).
Возможна операция синхронизации классов и UI (в файлах UI свойства контролек,
отмеченных как обновляемые, обновляются по измененному и свойству класса).
Кроме это "движок" обеспечивает запуск форм, взаимодействие между собой.
Вообще "движок" реализует дефолтные варианты след. инерфейсов:
— контрольки, их сериализация в XML
— взаимодействие форм (функции запуска форм, решение конфликтов одновременного изменения
одних и тех же данных, для отображения используем dockpanelsuite)
— стиль контролек
— сохранение объектов (используется реализация для db4o)
Расширение или адаптация движка под конкретный проект
может заключаться в добавлении новых контролек в язык,
возможен более простой вариант "вкодирования" в соответствующую форму
(так как раз делаем с флеш-фрагментами в мед.проекте, на базе которого
апробируем "движок"). Кроме этого интерфейсы каждой части "движка"
можно реализовать по-своему. Например, для хранения, вполне возможна
реализация соответствующего провайдера для nhibernate.
Возможно, полезность и универсальность такого подхода в целом не очень высока, но
в случае нескольких медицинских проектов, с которыми я сталкивался,
подобный движок (как показывает последний проект ) весьма к месту.
Здравствуйте, WoldemaR, Вы писали:
WR>Что вы об этом думаете? Меня интересуют критические замечания об этом подходе как теоритического так и практического характера.
Думаю, что для пользователей-программистов это вполне подходит — они уже привыкли работать со списками свойств объектов, с базами данных в "чистом виде", без форм.
В применении описанного подхода для обычных пользователей — сильно сомневаюсь. Работать с формой заведомо легче и приятнее, чем со списком свойств. Чем больше атрибутов — тем хуже воспринимается список, труднее находить нужный атрибут.
Вы экономите на скорости разработки и сильно теряете в качестве пользовательского интерфейса.
Вообще, конечно, странно видеть призыв возврата к data-driven UI. Видимо, Купер, Раскин и прочие старались зря...
Речь не идет о генерации data-driven UI и его последующем использовании один-в-один в чистом виде.
Мой "тезис" такой: между ФРАГМЕНТАМИ модели предметной области и модели UI существует
взаимно-однозначное соответствие. А это повод для избавления от рутины.
Это никак не противоречит последующей специализации UI дизайнерами.
Данное направление нисколько не устарело. Совсем недавно попалась свежая статья
с близкими идеями.
N>Думаю, что для пользователей-программистов это вполне подходит — они уже привыкли работать со списками свойств объектов, с базами данных в "чистом виде", без форм. N>В применении описанного подхода для обычных пользователей — сильно сомневаюсь. Работать с формой заведомо легче и приятнее, чем со списком свойств. Чем больше атрибутов — тем хуже воспринимается список, труднее находить нужный атрибут. N>Вы экономите на скорости разработки и сильно теряете в качестве пользовательского интерфейса.
N>Вообще, конечно, странно видеть призыв возврата к data-driven UI. Видимо, Купер, Раскин и прочие старались зря...
компилятора нету...
Юзабилити там цветет и пахнет с еще большей силой.
1.1.4 stable rev. 510
Издательство: Символ-Плюс
Издательство: Вильямс
