|
Генерация пользовательского интерфейса
|
|||
---|---|---|---|
#18+
Все это уже было. Но стоит только шагнуть в сторону и вся эта стройная система, созданная для нескольких типовых документов, идет в лес. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.09.2012, 13:46 |
|
Генерация пользовательского интерфейса
|
|||
---|---|---|---|
#18+
Sergey_rb, да, очень похоже на мою задумку. Только формируются формы по интерфейсу объекта. Свойства компонентов я разделил на: - относящиеся к логике взаимодействию с интерфейсом модели - к внешнему виду. Например доступность для редактирования определяются интерфейсом модели. Для понимания Код: c# 1.
привязанный компонент будет доступен для редактирования Код: c# 1.
только для чтения. У меня это реализовано по-другому, вместо int использовал свои специально обученные на взаимодействия с представлением классы. Но суть такая. В С# нельзя менять атрибуты private на public во время выполнения программы, много чего нельзя. Нужен либо динамически типизированный либо эмулировать это. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.09.2012, 14:07 |
|
Генерация пользовательского интерфейса
|
|||
---|---|---|---|
#18+
d8m1kВ С# нельзя менять атрибуты private на public во время выполнения программы, много чего нельзя. Нужен либо динамически типизированный либо эмулировать это. можно сгенерировать нужные классы из метаданных а ваще нафиг не нужны эти классы, все генерируем из метаданных,а если уж кому то невмоготу без классов, то суем ему дайнамик ... |
|||
:
Нравится:
Не нравится:
|
|||
19.09.2012, 14:36 |
|
Генерация пользовательского интерфейса
|
|||
---|---|---|---|
#18+
d8m1k Программный интерфейс классов однозначно отображается на визуальный интерфейс. это одна из главных ошибок. Класс может быть один, а интерфейсов более одного. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.09.2012, 14:52 |
|
Генерация пользовательского интерфейса
|
|||
---|---|---|---|
#18+
d8m1kSergey_rb, да, очень похоже на мою задумку. Только формируются формы по интерфейсу объекта. Свойства компонентов я разделил на: - относящиеся к логике взаимодействию с интерфейсом модели - к внешнему виду. Например доступность для редактирования определяются интерфейсом модели. Для понимания Код: c# 1.
привязанный компонент будет доступен для редактирования Код: c# 1.
только для чтения. У меня это реализовано по-другому, вместо int использовал свои специально обученные на взаимодействия с представлением классы. Но суть такая. В С# нельзя менять атрибуты private на public во время выполнения программы, много чего нельзя. Нужен либо динамически типизированный либо эмулировать это. ничего не понял. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.09.2012, 15:10 |
|
Генерация пользовательского интерфейса
|
|||
---|---|---|---|
#18+
iscrafmd8m1k Программный интерфейс классов однозначно отображается на визуальный интерфейс. это одна из главных ошибок. Класс может быть один, а интерфейсов более одного. Не верно выразился. Вернее будет: Вид дерева объектов однозначно отображается на визуальный интерфейс. Но это упрощённо. На самом деле даже один и тот же объект в разных местах дерева может отображаться по-разному. Например список как таковой и список в качестве словаря для выбора. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.09.2012, 16:31 |
|
Генерация пользовательского интерфейса
|
|||
---|---|---|---|
#18+
А что, в список для выбора пользователь не может добавлять записи? ... |
|||
:
Нравится:
Не нравится:
|
|||
19.09.2012, 16:53 |
|
Генерация пользовательского интерфейса
|
|||
---|---|---|---|
#18+
Sergey_rb, попробую пояснить. Гипотетический генератор UI сканирует контейнер в модели - ищет все открытые свойства и методы. Если он найдёт Код: c# 1.
то создаст TextBox и свяжет его с Value двусторонне. Т.е. при изменении значения в TextBox будет присваивать это значение Value. А если встретит Код: c# 1.
то поймёт, что присваивать значение Value нельзя, поэтому логично сделать TextBox недоступным для редактирования. Реакцию на TextBox на изменение Value можно было бы устроить если бы существовало некие события возникающие автоматически перед и после присвоения значения свойству Value. private или public, определяющие видимость свойств можно тоже задать только один раз при написании программы. Поэтому на самом деле я использую некий класс MyInt у которого есть события ValueChanging, ValuetChanged, свойство public int Value. Так же свойство Visible, заменяющее модификатор доступа public/не public. Использую эти классы следующим образом Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.
В объекте Value перед и после присваивания возникают события ValueChanging, ValueChanged. На изменение Visible тоже события, которые понимает генератор представления и адекватно реагирует. Так как Visible относиться к подобному типу MyBoolean устроенному по аналогии. В представлении TextBox можно настроить: внешний вид, расположение, прилепить Caption, Hint. Всё это запомнить относительно положения Value в модели. А следующий раз оно воспроизведётся. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.09.2012, 16:56 |
|
Генерация пользовательского интерфейса
|
|||
---|---|---|---|
#18+
Sergey_rbА что, в список для выбора пользователь не может добавлять записи? Извините, не понял... ... |
|||
:
Нравится:
Не нравится:
|
|||
19.09.2012, 16:59 |
|
Генерация пользовательского интерфейса
|
|||
---|---|---|---|
#18+
d8m1kSergey_rbА что, в список для выбора пользователь не может добавлять записи? Извините, не понял... Есть список выбора, но пользователю иногда надо прямо в этой форме добавить запись в этот список. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.09.2012, 17:09 |
|
Генерация пользовательского интерфейса
|
|||
---|---|---|---|
#18+
d8m1kSergey_rb, попробую пояснить. Гипотетический генератор UI сканирует контейнер в модели - ищет все открытые свойства и методы. Если он найдёт Код: c# 1.
то создаст TextBox и свяжет его с Value двусторонне. Т.е. при изменении значения в TextBox будет присваивать это значение Value. А если встретит Код: c# 1.
то поймёт, что присваивать значение Value нельзя, поэтому логично сделать TextBox недоступным для редактирования. Реакцию на TextBox на изменение Value можно было бы устроить если бы существовало некие события возникающие автоматически перед и после присвоения значения свойству Value. private или public, определяющие видимость свойств можно тоже задать только один раз при написании программы. Поэтому на самом деле я использую некий класс MyInt у которого есть события ValueChanging, ValuetChanged, свойство public int Value. Так же свойство Visible, заменяющее модификатор доступа public/не public. Использую эти классы следующим образом Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.
В объекте Value перед и после присваивания возникают события ValueChanging, ValueChanged. На изменение Visible тоже события, которые понимает генератор представления и адекватно реагирует. Так как Visible относиться к подобному типу MyBoolean устроенному по аналогии. В представлении TextBox можно настроить: внешний вид, расположение, прилепить Caption, Hint. Всё это запомнить относительно положения Value в модели. А следующий раз оно воспроизведётся. А если это поле не должен редактировать один пользователь, но должен редактировать другой? Или документ находится в статусе редактирования, потом переходит в другой статус и закрывается для редактирования? ... |
|||
:
Нравится:
Не нравится:
|
|||
19.09.2012, 17:11 |
|
Генерация пользовательского интерфейса
|
|||
---|---|---|---|
#18+
Sergey_rbЕсть список выбора, но пользователю иногда надо прямо в этой форме добавить запись в этот список. Непосредственно в список по задумкие почему нет. Список - массив элементов. Тоже может быть связан с моделью. Модель может разрешить добавлять элементы пользователю. Можно чуточку поконкретней, если не сложно? Список не сам по-себе он где-то используется? ... |
|||
:
Нравится:
Не нравится:
|
|||
19.09.2012, 17:52 |
|
Генерация пользовательского интерфейса
|
|||
---|---|---|---|
#18+
А если это поле не должен редактировать один пользователь, но должен редактировать другой? Значит экземпляр приложения одного пользователя должен создавать поле доступным, а у дрогого недоступным. К сожалению не получается для одного пользователя создать Код: c# 1.
а для другого Код: c# 1.
Зато можно всё это реализовать в MyInt, например ввести понимаемое генератором UI свойство ReadOnly или Enabled. Или документ находится в статусе редактирования, потом переходит в другой статус и закрывается для редактированияаналогично ... |
|||
:
Нравится:
Не нравится:
|
|||
19.09.2012, 18:00 |
|
Генерация пользовательского интерфейса
|
|||
---|---|---|---|
#18+
Пользователь заполняет приходную накладную. В накладной есть товар, которого нет в базе. Пользователю надо добавить товар в базу не закрывая формы приходной накладной. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.09.2012, 18:01 |
|
Генерация пользовательского интерфейса
|
|||
---|---|---|---|
#18+
Sergey_rb, пример ясен. Да. На уровне модели есть этот список. На уровне представления грид, связанный с этим списком. Модель разрешает представлению редактировать список, предоставляет ему интерфейс для редактирования например IList<object> если на C#, вместо IEnumirable<object> Генератор UI понимает это и создаёт грид редактируемым. При добавлении строки сообщает модели, что добавилась строка. В модели на событие изменения таблицы тоже могут быть навешаны свои обработчики, благодаря чему модель можно запрограммировать, например, сохранять изменения сразу, а так же обновлять логически связанные элементы. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.09.2012, 18:34 |
|
Генерация пользовательского интерфейса
|
|||
---|---|---|---|
#18+
Sergey_rbВсе это уже было. Но стоит только шагнуть в сторону и вся эта стройная система, созданная для нескольких типовых документов, идет в лес.Мне самому интересно насколько описываемая система жизнеспособна. Насколько много всевозможных необходимых вариантов визуализации или можно для большинства применений ограничиться каким то конечным набором. По аналогии как например достаточно базовых типов данных в языке программирования: строка, массив, запись. Вижу такая система плохо подходит для написания игрушек, интернет-магазинов, отчётной системы... Но для ведения учётов, картотек, где оперируют небольшим наборов типов данных однообразным образом. Хочется понять насколько там возможны различные непредсказуемые вариации. Буду рад каким либо примерам ... |
|||
:
Нравится:
Не нравится:
|
|||
19.09.2012, 18:43 |
|
Генерация пользовательского интерфейса
|
|||
---|---|---|---|
#18+
Sergey_rbПользователю надо добавить товар в базу не закрывая формы приходной накладной. Ессно. Но для этого придумали MDI ... |
|||
:
Нравится:
Не нравится:
|
|||
20.09.2012, 09:57 |
|
Генерация пользовательского интерфейса
|
|||
---|---|---|---|
#18+
d8m1kSergey_rbВсе это уже было. Но стоит только шагнуть в сторону и вся эта стройная система, созданная для нескольких типовых документов, идет в лес.Мне самому интересно насколько описываемая система жизнеспособна. Насколько много всевозможных необходимых вариантов визуализации или можно для большинства применений ограничиться каким то конечным набором. По аналогии как например достаточно базовых типов данных в языке программирования: строка, массив, запись. Вижу такая система плохо подходит для написания игрушек, интернет-магазинов, отчётной системы... Но для ведения учётов, картотек, где оперируют небольшим наборов типов данных однообразным образом. Хочется понять насколько там возможны различные непредсказуемые вариации. Буду рад каким либо примерам Есть некий справочник. Из одной формы он должен предлагать все записи. Из другой - только актуальные на сегодня. Из третьей - с учетом значения, введеного в соседнем контроле. Куда предполагается долепить дополнительные условия выборки, к какому объекту привязать? ... |
|||
:
Нравится:
Не нравится:
|
|||
20.09.2012, 11:13 |
|
Генерация пользовательского интерфейса
|
|||
---|---|---|---|
#18+
Cane Cat FisherЕсть некий справочник. Из одной формы он должен предлагать все записи. Из другой - только актуальные на сегодня. Из третьей - с учетом значения, введеного в соседнем контроле. Куда предполагается долепить дополнительные условия выборки, к какому объекту привязать?Иметь возможность открывать выборку с фильтром. Набор возможных фильтров привязать к самой выборке настроенной в метаданных. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.09.2012, 12:11 |
|
Генерация пользовательского интерфейса
|
|||
---|---|---|---|
#18+
d8m1kSergey_rb, пример ясен. Да. На уровне модели есть этот список. На уровне представления грид, связанный с этим списком. Модель разрешает представлению редактировать список, предоставляет ему интерфейс для редактирования например IList<object> если на C#, вместо IEnumirable<object> Генератор UI понимает это и создаёт грид редактируемым. При добавлении строки сообщает модели, что добавилась строка. В модели на событие изменения таблицы тоже могут быть навешаны свои обработчики, благодаря чему модель можно запрограммировать, например, сохранять изменения сразу, а так же обновлять логически связанные элементы. Добавлять надо не в гриде, а в форме ввода товарной позиции со всеми проверками. Иначе получается что-то вроде 1С. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.09.2012, 12:53 |
|
Генерация пользовательского интерфейса
|
|||
---|---|---|---|
#18+
Sergey_rbДобавлять надо не в гриде, а в форме ввода товарной позиции со всеми проверками. а в гриде разве проверок нет? если в системе существует какая-то зависимость от того, в какой форме в нее можно добавить запись, то явно где-то прокол в ее архитектуре. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.09.2012, 13:03 |
|
Генерация пользовательского интерфейса
|
|||
---|---|---|---|
#18+
Cane Cat FisherЕсть некий справочник. Из одной формы он должен предлагать все записи. Из другой - только актуальные на сегодня. Из третьей - с учетом значения, введеного в соседнем контроле. Куда предполагается долепить дополнительные условия выборки, к какому объекту привязать? Предлагаю делегировать дополнительные условия в отдельный класс, скажем AdditionalFilterBase Схематично так: Сам справочник Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14.
Вынесенный шаблон фильтра Код: c# 1. 2. 3.
Конкретные варианты этого вынесенного фильтра Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16.
Экземпляры справочника. В одном месте модели так Код: c# 1.
В другом так: Код: c# 1.
В третьем так: Код: c# 1.
Разные hb создаются в разных местах модели. Получается класс 1 а объекты по разному устроены. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.09.2012, 14:01 |
|
Генерация пользовательского интерфейса
|
|||
---|---|---|---|
#18+
Sergey_rbДобавлять надо не в гриде, а в форме ввода товарной позиции со всеми проверками. В принципе возможно валидация в строке грида так же как на форме. Строка грида - это тот же набор полей. Валидация относиться к функциональности и логично вынести код валидации в модель. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.09.2012, 14:07 |
|
Генерация пользовательского интерфейса
|
|||
---|---|---|---|
#18+
d8m1kSergey_rbДобавлять надо не в гриде, а в форме ввода товарной позиции со всеми проверками. В принципе возможно валидация в строке грида так же как на форме. Строка грида - это тот же набор полей. Валидация относиться к функциональности и логично вынести код валидации в модель. Как будет осуществлен контроль ввода на уровне прав пользователей? Допустим кладовщик не имеет право редактировать поле "Заказано", его может править только менеджер и только когда документ в статусе заказа. И наоборот, менеджер не имеет права править поле "Отпущено", а кладовщик имеет. Когда документ переходит в статус "отгружено", то уже никто не имеет права редактировать эти поля. А поле "цена" может видеть только менеджер и не имеет права ВИДЕТЬ кладовщик. Как это собираетесь реализовать в гриде? ... |
|||
:
Нравится:
Не нравится:
|
|||
21.09.2012, 10:33 |
|
Генерация пользовательского интерфейса
|
|||
---|---|---|---|
#18+
Sergey_rbКак будет осуществлен контроль ввода на уровне прав пользователей? Допустим кладовщик не имеет право редактировать поле "Заказано", его может править только менеджер и только когда документ в статусе заказа. И наоборот, менеджер не имеет права править поле "Отпущено", а кладовщик имеет. Когда документ переходит в статус "отгружено", то уже никто не имеет права редактировать эти поля. А поле "цена" может видеть только менеджер и не имеет права ВИДЕТЬ кладовщик. Как это собираетесь реализовать в гриде?Ввести такое понятие, как флаг запрета в гриде. По состоянию этого флага нужные поля разрешаются/запрещаются. Разумеется выборка должна знать, кто именно ее "вычитал". ... |
|||
:
Нравится:
Не нравится:
|
|||
21.09.2012, 10:42 |
|
|
start [/forum/topic.php?fid=33&msg=37964197&tid=1547771]: |
0ms |
get settings: |
9ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
29ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
65ms |
get tp. blocked users: |
1ms |
others: | 295ms |
total: | 434ms |
0 / 0 |