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

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.

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

Кстати, какие существуют популярные генераторы UI
или визуальные редакторы data-driven UI?

Слышал, что такое есть в САП, не обманывают?

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

S>Кстати, какие существуют популярные генераторы UI
S>или визуальные редакторы data-driven UI?

Посмотри Автоматическая генерация GUI

Автор: Lazy Cjow Rhrr
Дата: 21.07.06

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

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

Думаю, что для пользователей-программистов это вполне подходит — они уже привыкли работать со списками свойств объектов, с базами данных в "чистом виде", без форм.
В применении описанного подхода для обычных пользователей — сильно сомневаюсь. Работать с формой заведомо легче и приятнее, чем со списком свойств. Чем больше атрибутов — тем хуже воспринимается список, труднее находить нужный атрибут.
Вы экономите на скорости разработки и сильно теряете в качестве пользовательского интерфейса.

Вообще, конечно, странно видеть призыв возврата к data-driven UI. Видимо, Купер, Раскин и прочие старались зря...

Речь не идет о генерации data-driven UI и его последующем использовании один-в-один в чистом виде.
Мой "тезис" такой: между ФРАГМЕНТАМИ модели предметной области и модели UI существует
взаимно-однозначное соответствие. А это повод для избавления от рутины.
Это никак не противоречит последующей специализации UI дизайнерами.

Данное направление нисколько не устарело. Совсем недавно попалась свежая статья
с близкими идеями.


N>Думаю, что для пользователей-программистов это вполне подходит — они уже привыкли работать со списками свойств объектов, с базами данных в "чистом виде", без форм.
N>В применении описанного подхода для обычных пользователей — сильно сомневаюсь. Работать с формой заведомо легче и приятнее, чем со списком свойств. Чем больше атрибутов — тем хуже воспринимается список, труднее находить нужный атрибут.
N>Вы экономите на скорости разработки и сильно теряете в качестве пользовательского интерфейса.

N>Вообще, конечно, странно видеть призыв возврата к data-driven UI. Видимо, Купер, Раскин и прочие старались зря...