Re[2]: Общие принципы организации GUI для редактирования модели данных
От: _hum_ Беларусь  
Дата: 07.08.13 16:24
Оценка:
Здравствуйте, maxkar, Вы писали:

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


__>>Далее,

__>>1) забираем информацию, введенную пользователем;
__>>2) проверяем ее на совместимость в модели (чтобы не нарушить целостность последней);
__>>3) если все ОК, то обновляем модель и обновляем представление, если нет, то выдаем какое-то сообщение о невозможности.

M>Не обязательно. Подобная проверка может выполняться прямо в процессе ввода. Нужно смотреть на конкретные требования.


Проверка в процессе ввода выглядит слишком вычурной.

__>>Тут вроде все ясно. Но! В большинcтве графических элементов ввода информации (текстовых полей, лист-контролов, таблиц) таких явных разделений на этапы инициации, ввода данных и подтверждения завершения ввода нет.


M>Правильно. Нет.

M> 1. Компонент отображает только часть данных. "Текстовое поле" — это всего лишь часть сложного объекта данных. Может быть ситуация, когда нужно валидировать содерижмое нескольких полей вместе и сообщение о валидации не может быть привязано к отдельному визуальному компоненту.
M> 2. Способов отображения невалидного состояния много. Можно отображать в самом контроле (или подсвечивать только неверную часть). Можно рядом с контролом. Можно вообще в отдельной области уведомлений (я так делал в одном приложении, в случае ошибок выводятся ошибки, в остальном — некоторая диагностика).
M> 3. Для большинства компонентов характерно наличие невалидных данных в процессе ввода.

Вопрос же был не в том, как именно выдавать сообщение об ошибочных данных, а в том, как узнать, что процесс ввода завершен, и можно эту проверку начинать.
И да, хоть, как вы говорите, "может быть ситуация, когда нужно валидировать содерижмое нескольких полей вместе", это ничего не меняет, так как фокус ввода всегда находится на каком-то конкретном поле, а значит, именно его данные в данный момент редактируются и ответственны за нарушение целостности — все остальные УЖЕ ВНЕСЕНЫ В МОДЕЛЬ и проблемы с нарушением целостности не представляют (а "подсветить" их при необходимости — плевое дело).

__>>Как быть в таких случаях с проверкой на целостность?

M>Зависит от приложения. Вариантов масса:
M> 1. Выполнять валидацию "на лету" и выводить нужные подсказки.

Не вариант — см. выше.

M> 2. Выполнять валидацию только по нажатию кнопки и подсвечивать "Невалидные" поля.


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

M> 3. Выполнять валидацию по клику и выводить информацию об ошибках в отдельном окне.


По какому клику? Вне зоны фокуса редактирования?

M>Данные очень разные и решения нужно подбирать к конкретным вводимым данным и сценариям пользователей. И от самого приложения тоже много зависит. В веб и "толстом клиенте" могут использоваться разные подходы (из-за ограничений архитектуры или используемых библиотек).


Это понятно, но неужели надо каждый раз изобретать велосипеды? Вроде ж какие-то концепты на эту тему типа MVC, MVP и проч. разрабатывались. Нет?


В явном виде у меня это проблема проявилась при работе с таблицами (данные моей модели представляются в виде таблицы). Если начало редактирования здесь еще явное (пользователь щелкает мышью по ячейке — на месте ячейки вставляется появляется LineEdit, позволяющий осуществлять ввод), то с его завершением полные непонятки. В большинстве случаев неявно пользователю предлагается кликнуть где-нибудь на другой ячейке ("отщелкнуть"), чтобы "подтвердить ввод" тех данных, которые он вводил. Но! Во-первых, это настолько неявно, что многие пользователи просто этого не знают, из-за чего происходят ошибки (например, не "отщелкнул" последнее введенное значение и закрыл программу). Во-вторых, поскольку обычно вид LineEdit отличается от вида ячейки только моргающим курсором, то для пользователя не очевиден момент: он при вводе значения СРАЗУ меняет это значение в модели, или это изменение происходит только после "отщелкивания"? Ну и, в-третьих, нет возможности отмены введенного значения до его подтверждения (типа функции кнопки cancel в диалоговом окне редактирования).
Из этого я сделал вывод, что такое табличное представление (такой табличный контрол) нацелен именно на синхронное изменение данных в модели:
ввод данных в представление -> синхронное изменение данных в модели

(тогда все как бы ясно, кроме момента с "отщелкиванием" — непонятно, зачем он нужен).
Но как быть, когда хочется использовать табличное представление с асинхронным изменением модели:
ввод данных в представление -> подтверждение/отмена ввода -> валидация данных -> изменение данных в модели/отказ в изменении

?
Интуитивно кажется, что в таких случаях при работе пользователя с представлением обязательно в явном виде должны выделяться три момента, о которых я ранее говорил:
1) пользовательская инициация ввода данных
2) пользовательский ввод данных
3) пользовательское подтверждения окончания ввода данных или отмены

Для таблицы это должно было бы, например, выглядеть так:
1) щелчок по ячейке — появление в области ячейки минидиалогового окошка с LineEdit и двумя миникнопками, отвечающими "ОК", "Cancel".
2) ввод текста в LineEdit
3) нажатие кнопки "ОК"/"Cancel"
При попытке щелкнуть на другую ячейку при незавершенном нажатием одной из кнопок"ОК"/"Cancel", редактирование бы запрещалось (как в модальном диалоге).
Но почему-то я таких вариантов редактирования таблиц нигде не встречал....


Грубо говоря, если бы я задался целью написать некое абстрактное архитектурное решение, то, по идее, как минимум туда должны быть включены события, отвечающие трем указанным пунктам. Но из проштудированной пока инфы я ничего подобного не нашел...Вот и весь в раздумьях, на какие принципы опираться при написании проги...
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.