Методы организации добавления записи в таблицу...

← →
Cyrax © (2007-05-06 21:41) [0]

...на уровне пользовательского интерфейса:
1) Последняя строка таблицы - пустая, со звёздочкой. Начинаем туда писать - звёздочка исчезает, появляется ручка, ниже появляется ещё одна строка со звёздочкой. В итоге имеем две дополнительные строки - информация ни из одной из них в БД не сохранена, непонятно чего делаем... бардак...
2) Нажимаем кнопку типа "добавить" - открывается окно с полями, которые нужно заполнить, либо заполняем поля в том же окне рядом (скажем, ниже) с таблицей. Жмём "Сохранить" - в таблице появляется новая строка.
Здесь не нарушается принцип отображения в таблице только тех данных, которые имеются в БД.

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

← →
DVM © (2007-05-06 21:46) [1]

> Есть ли ещё какие-либо шаблоны для организации процесса
> добавления пользователем строки с данными в таблицу ?

Второй вариант имхо лучше.

Я часто делаю еще так. Есть окно с таблицей. Внизу кнопка добавить. При нажатии на кнопку Добавить окно увеличивается по вертикали и внизу поля для ввода данных. Там же кнопки сохранить и отмена. При нажатии на любую из них окно опять принимает прежний вид.

← →
Knight © (2007-05-06 21:48) [2]

> окно увеличивается по вертикали

А если окно развёрнуто на весь экран? :)

← →
DVM © (2007-05-06 23:09) [3]

> А если окно развёрнуто на весь экран? :)

Не я только для тех окон что не на весь экран. На весь экран они не могут - запрещено.

← →
Knight © (2007-05-06 23:12) [4]

> [3] DVM © (06.05.07 23:09)

Просто по практике&#133 часто на старых машинах с низким разрешением кнопок не видно, т.к. они уходят за нижний край экрана&#133 а тут ещё и увеличение :)

← →
Sergey13 © (2007-05-07 09:23) [5]

> [0] Cyrax © (06.05.07 21:41)

Как удобнее так и делай. Ни один из вариантов (при грамотной реализации) не противоречит ни Библии ни Корану ни Торе.

← →
Cyrax © (2007-05-07 11:32) [6]

Такое окно не должно быть большим. Ориентируемся, скажем, на 600x800 (с учётом рсширения окна). Располагаем элементы компактно. Если их много - перекидываем некоторые из них в другие окна, оставляем только те, которые нужны для работы с таблицей...

← →
Skyle © (2007-05-07 11:38) [7]

Сверху на тулбаре маленькие кнопки "Добавить", "Редактировать", "Удалить", на них есть хоткеи. А дальше вариант 2.

← →
ANB © (2007-05-07 12:47) [8]

> DVM © (06.05.07 21:46) [1]

Видел еще один подход - PageControl.
На одной вкладке - грид, на второй - окно с эдитами для текущей записи.
Можно переключиться и не нажимая кнопки добавить/редактировать - тогда будет только чтение.
В принципе - удобно. Я в одном микропроекте так сделал - юзеры довольны.
Расширение окна или статический показ в "подвале" - часто занимает много места и на экран не лезет.

← →
Skyle © (2007-05-07 13:10) [9]

> ANB © (07.05.07 12:47) [8]

Есть одно соображение: программа должна полноценно работать даже если на компьютере нет мыши.

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

А вот в маленьких формочках с одним гридом - вполне может быть, особенно если из общего стиля не выбивается.

← →
Игорь Шевченко © (2007-05-07 13:12) [10]

Второй вариант лучше

← →
Cyrax © (2007-05-08 08:59) [11]

1. Обычный редактируемый грид
2. Грид для просмотра + поля для ввода и корректироваки данных таблицы:
а) новое окно
б) динамическое расширение формы
в) использование вкладок

3. Более высокоуровневый интерфейс:
При редактировании поля/строки над таблицей выскакивает маленькое всплывающее окошко в виде облака (как речь в комиксах), исходящее из этого поля/строки с редактируемыми/заполняемыми полями и парой управляющих кнопок.
Дополнительная функциональность:
а) Можно опционально сделать регулируемую (по клавишам и с помощью маленького регулятора в углу) прозрачность этого окошка, чтобы в процессе редактирования были видны строки под этим окошком...
б) Возможность перемещения (и мышой, и клавой) этого окошка как в пределах формы, так и за её пределами, т.е. по всему экрану. При этом визуальная связь окошка с полем/записью таблицы будет сохранена (за счёт "отростка")))
Альтернатива 2-го варианта, но без его минусов.
Преимущества:
1) Занимает места не больше, чем сама таблица.
2) Окошко не загораживает таблицу (за счёт регулируемой прозрачности)
3) В таблице отображаются только те данные, которые имеются в БД
4) И просмотр, и редактирование/добавление записей в таблицу происходит на одной форме в одном месте (в отличие от вкладок)
5) Удобная визуализация связи этого окошка в полем/записью в таблице

з.ы. можно реализовать все 3 вида интерфейса опционально, каждый вид имеет несколько настраиваемых параметров...

← →
ЮЮ © (2007-05-08 10:00) [12]

> Здесь не нарушается принцип отображения в таблице только
> тех данных, которые имеются в БД.

Появление записи в локальном DataSet-е ещё не означает наличия этой записи в БД.

В реальных системах вводимый документ записывается во множество таблиц, поэтому связи 1 таблица - 1 грид оказывается недостаточно, а данные вводятся всё-таки в клиентские НД и лишь по кнопке "Сохранить" выполняется вставка во мнлжество связанных таблиц, поэтому "информация ни из одной из них в БД не сохранена, непонятно чего делаем... " не имеет под сабой никактх оснований

З.Ы. Предпочитаю делать формы ввода информации максимально похожими на документ, с которого информация вводится (в какой он выводится на печать)

← →
Cyrax © (2007-05-08 11:28) [13]

> Как удобнее так и делай. Ни один из вариантов (при грамотной реализации) не противоречит ни Библии ни Корану ни Торе.

Противоречит учению Маркса Карла Генриха и Энгельса Фридриха Фридриховича ...

> Появление записи в локальном DataSet-е ещё не означает наличия этой записи в БД.

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

> В реальных системах вводимый документ записывается во множество
> таблиц, поэтому связи 1 таблица - 1 грид оказывается недостаточно, а
> данные вводятся всё-таки в клиентские НД и лишь по кнопке "Сохранить"
> выполняется вставка во мнлжество связанных таблиц, поэтому
> "информация ни из одной из них в БД не сохранена, непонятно чего
> делаем... " не имеет под сабой никактх оснований

Доводы в пользу безосновательности утрированного высказывания насчёт "непонятно чего делаем" некорректны, поскольку после ввода очередной новой строки в гриде она может автоматически сохраняться в таблицах БД (впрочем, предпочитаю опциональную реализацию авто"save"а).
Кроме того, "БД", собственно, было употреблено в контексте понятия "клиентского НД" (информация с тех двух строк, о которых шла речь, не сохранена ни в БД, ни в клиентских НД)...

> З.Ы. Предпочитаю делать формы ввода информации максимально
> похожими на документ, с которого информация вводится (в какой он
> выводится на печать)

Максимально похожими на "документ, с которого информация вводится (в какой он выводится на печать)" следует делать, скорее, формы для просмотра (или состояния формы, предназначенные для просмотра, если форма служит как для просмотра, так и для редактирования/добавления данных). А формы (состояния форм) для редактирования/добавления записей следует всё же делать максимально удобными (и функционально, и визуально) именно для редактирования/добавления данных.
Просмотр же данных представлен обычным гридом. А вот организация редактирования/добавления данных как раз и рассматривается в этой ветке. И не обязательно эту часть процесса взаимодействия с пользователем делать в табличном виде...

Минусы табличного редактирования/добавления записей:
1. В случае длинных записей в полях при редактировании мы не видим всю запись целиком (2-й и 3-й способы позволяют этого избежать)...
2. Затрудняется визуальное восприятие и интуитивное разграничение данных, которые сохранены в БД/"клиентских НД" и которые "висят в воздухе"...
3. Невозможность в процессе ввода/редактирования данных просмотра тех записей грида, которые лежат за пределами видимой части грида (при наличии полос прокрутки), а также невозможность copy/paste"а из этих записей...

← →
Игорь Шевченко © (2007-05-08 11:30) [14]

Cyrax © (08.05.07 11:28) [13]

Ты б посмотрел на нормальные интерфейсы...хотя бы в продуктах Microsoft, там далеко не дураки в плане usability работают.

← →
Cyrax © (2007-05-08 11:49) [15]

Ты б посмотрел на нормальные интерфейсы...хотя бы в продуктах Microsoft, там далеко не дураки в плане usability работают.

И что это за "нормальные интерфейсы" ?
Частенько натыкаешся на грабли при работе с известными продуктами как в плане функциональности, так и usability...

← →
Галинка © (2007-05-08 13:58) [16]

защитникам второго варианта, а когда надо ввести пару сотен строк? Это каждый раз окошко вызывать? Мигание запарит ((

ИМХО зависит от рода и количества иныормации.

1. Если редактируемая/добавляемая строка сожержит всего два-три поля, информация в полях достаточно примитивна (типа наименование товара, цена, количество), но таких строк надо ввести больше 20 за раз, то писать ради этого новое окошко - это как из пушки по воробъям.

2. Если же строка содержит много полей разного типа, то дополнительное окно для ввода себя оправдает.

← →
Игорь Шевченко © (2007-05-08 14:00) [17]

> защитникам второго варианта, а когда надо ввести пару сотен
> строк? Это каждый раз окошко вызывать? Мигание запарит ((

А кто же в здравом уме вводит такое количество ? Только кому делать нечего.

Cyrax © (08.05.07 11:49) [15]

> И что это за "нормальные интерфейсы" ?

Например, MS Access

> Частенько натыкаешся на грабли при работе с известными продуктами
> как в плане функциональности, так и usability...

Примеры в студию

← →
Sergey13 © (2007-05-08 14:09) [18]

> [13] Cyrax © (08.05.07 11:28)
> Противоречит учению Маркса Карла Генриха и Энгельса Фридриха
> Фридриховича

В каком пункте?

← →
etc (2007-05-08 16:29) [19]

> А кто же в здравом уме вводит такое количество ? Только
> кому делать нечего

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

← →
Cyrax © (2007-05-08 18:51) [20]

> таких строк надо ввести больше 20 за раз

Как можно за раз ввести 20 строк ??? Телепатически ?..
Я могу только по очереди 20 строк ввести. Ввёл 1-ю строку, сохранил, ввёл 2-ю, сохранил и т.д.

> Например, MS Access

Устаревший интерфейс. Собственно, 1-й вариант, имеющий всего лишь одно преимущество (перед 2-м вариантом, но не перед 3-м): компактность... При наличии всех недостатков 2-го и 3-го способов...

> Примеры в студию

ERWin, BPWin, Adobe Photoshop, Corel Draw... Бофа на поднос не влезло... Придётся звать следующую ассистентку...

>В каком пункте?

На память не припомню...
Тебе действительно интересно ?..

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

← →
alien1769 © (2007-05-08 19:03) [21]

> По поводу 200 записей. Не пойму, каким образом количество
> вводимых записей может влиять на организацию процесса добавления
> в таблицу

Ввод суммы премий для сотрудников. Для бухгалтера оптимально - таблица на экране с сотрудниками и суммой. Набор идет 3-5 минут.

← →
Cyrax © (2007-05-08 19:07) [22]

> Ввод суммы премий для сотрудников. Для бухгалтера оптимально -
>таблица на экране с сотрудниками и суммой. Набор идет 3-5 минут.

Имеется ввиду простота перехода по ячейкам по вертикали (клавой) ?

← →
Johnmen © (2007-05-08 19:18) [23]

> Игорь Шевченко © (08.05.07 14:00) [17]
> > защитникам второго варианта, а когда надо ввести пару
> сотен > строк? Это каждый раз окошко вызывать? Мигание запарит
> ((А кто же в здравом уме вводит такое количество ? Только
> кому делать нечего.

Как раз вводят те, кто напряженно работает, а не флудит на форумах.
Ярчайший пример - ввод заказов со многими позициями. Где от скорости ввода зависит всё.
А в этом случае - только вариант 1. Но то, что описал автор - это проявления некорректно написанной программы.

← →
Cyrax © (2007-05-08 19:31) [24]

>Ярчайший пример - ввод заказов со многими позициями. Где от скорости >ввода зависит всё.
>А в этом случае - только вариант 1.

Скажем, 20 позиций. Тогда вовсю будем катать грид влево-вправо, когда намного удобнее оформлять заказ на новой сущности/control"е...

Но то, что описал автор - это
>проявления некорректно написанной программы.

Хотя бы пару минусов 3-го способа добавления записи в таблицу...

← →
Johnmen © (2007-05-08 19:34) [25]

> Тогда вовсю будем катать грид влево-вправо, когда намного
> удобнее оформлять заказ на новой сущности/control"е...

Я не понял, что за "катания вправо-лево".

> Хотя бы пару минусов 3-го способа добавления записи в таблицу...

Где он, о чем он?

← →
Cyrax © (2007-05-08 19:39) [26]

Я не понял, что за "катания вправо-лево".

20 полей на экране не влезут в одну строку. Поэтому придётся работать горизонтальной полосой прокрутки. При этом мы не будем видеть всех полей заказа...

Где он, о чем он?

11-й пост...

← →
Johnmen © (2007-05-08 19:45) [27]

> 20 полей на экране не влезут в одну строку.

Понятно. Ты никогда не видел, как вводятся заказы, и что там за поля.

> 11-й пост...

Каждый волен придумать себе свою игрушку и реализовать её.

← →
Cyrax © (2007-05-08 19:51) [28]

Понятно. Ты никогда не видел, как вводятся заказы, и что там за поля.
Просвети, что там за волшебные поля...

Каждый волен придумать себе свою игрушку и реализовать её.

Всё понятно...

> Просвети, что там за волшебные поля...

Там обычные поля. И число их В ПРИНЦИПЕ не м.б. более 5-6. Причем заполняются только 3-4. Я говорю не о шапке заказа, а о списке содержимого.

> Там обычные поля. И число их В ПРИНЦИПЕ не м.б. более 5-6. Причем
> заполняются только 3-4. Я говорю не о шапке заказа, а о списке
> содержимого.

И чем хуже 2-й и 3-й варианты ?

> И чем хуже 2-й и 3-й варианты ?

Второй вариант не позволяет вводить быстро. Требует доп.ресурсов и обработчиков.

да вспомните хотя бы Excel. Все там удобно для несложных несвязанных данных.

Любой "наворот" должен себя оправдывать ))

Игорь Шевченко © (08.05.07 14:00) [17]

"Ты конечно программер авторитетный", но надо смотреть не только на процесс разработки. Бывают случаи, когда программы пишутся для автоматизации некоторых расчетов, статистический в том числе, данные для которых есть ТОЛЬКО НЕ БУМАГЕ. Не было во время составления данных еще компов (у нас была бумажная "база данных" землетрясений с 1892 года, 36 томов/тетрадий полевых испытаний записанных от руки). Вот и приходилось потом сидеть и тупо загонять данные хотя бы в Акцесс. Для облегчения работы будущим поколениям программеров. Которые придут потом на все готовое )))

и вот бы с меня семь потов сошло, если б какой-нибудь м***... умный человек придумал бы туда дополнительные формочки на каждый ввод ((( я человек не злобливый, но я б точно прокляла ))

Cyrax © (08.05.07 18:51) [20]

А ты отвлекись на минуту от "аппаратной" части и поставь себя на место юзверя твоего будущего шедевра. )) Одно дело когда нада энтер дрюкнуть, и все сохранилось (не важно в НД, или базе или еще где). И совсем другое дело, когда у тебя двести раз окошко (новая сущность) вылазит, по которому надо в лучшем случае табом передвигаться, да потом еще кнопку "ОК" жать...

> да вспомните хотя бы Excel. Все там удобно для несложных несвязанных
>данных.

Excel - это электронная таблица, идеология которой построена именно на ячейках... Иные способы ввода данных (в частности, через какие-то дополнительные формы/сущности) там не подразумеваются.

> А ты отвлекись на минуту от "аппаратной" части и поставь себя на
> место юзверя твоего будущего шедевра. )) Одно дело когда нада энтер
> дрюкнуть, и все сохранилось (не важно в НД, или базе или еще где). И
> совсем другое дело, когда у тебя двести раз окошко (новая сущность)
> вылазит, по которому надо в лучшем случае табом передвигаться, да
> потом еще кнопку "ОК" жать...

Абсолютно те же самые "дрюканья" можно проделать и с новой сущностью (которую даже окошком не назовёшь), безо всякой мыши (tab"ы, да Enter, и всё, никаких OK). В этом плане 3-й пункт ничуть не уступает 1-му по скорости ввода большого массива данных.
Но при этом мы получаем одно важное преимущество (которое в данном случае имеет наибольший вес) - мы видим все вводимые данные целиком, в отличие от таблицы, где все поля расположены в одну строку.
Более того, мы получаем ряд дополнительных преимуществ (которые в случае ввода большого массива данных имеют меньший вес), перечисленных в 11-м посте...

> [20] Cyrax © (08.05.07 18:51)
> Тебе действительно интересно ?..

Еще как! Ты ж этим утверждением все мои моральные устои опустил ниже плинтуса. 8-)

Cyrax © (08.05.07 18:51) [20]

> Устаревший интерфейс.

MS так не считает...

> > Примеры в студию
>
> ERWin, BPWin, Adobe Photoshop, Corel Draw

Я как бы в этих программах форм ввода, а в особенности массового не увидел. Плохо смотрел ?

Johnmen © (08.05.07 19:18) [23]

> Как раз вводят те, кто напряженно работает, а не флудит
> на форумах.
> Ярчайший пример - ввод заказов со многими позициями. Где
> от скорости ввода зависит всё.

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

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

Галинка © (09.05.07 13:21) [32]

> "Ты конечно программер авторитетный", но надо смотреть не
> только на процесс разработки. Бывают случаи, когда программы
> пишутся для автоматизации некоторых расчетов, статистический
> в том числе, данные для которых есть ТОЛЬКО НЕ БУМАГЕ. Не
> было во время составления данных еще компов (у нас была
> бумажная "база данных" землетрясений с 1892 года, 36 томов/тетрадий
> полевых испытаний записанных от руки). Вот и приходилось
> потом сидеть и тупо загонять данные хотя бы в Акцесс. Для
> облегчения работы будущим поколениям программеров. Которые
> придут потом на все готовое )))

Эта...одно дело сделать разовую работу по вводу данных, для этого можно взять любой подходящий инструмент, вплоть до системы FOCUS имени Юрия Сальникова с ее "вводом текста с рукописи" (кто знает, тот поймет).

Другое дело - это писать программу для постоянной работы. Я не думаю, что данные о землетрясениях и в дальнейшем будут регистрироваться только на бумаге - нафига ж, спрашивается, уже который год подряд школьников учат программам MS ?

> Игорь Шевченко © (10.05.07 13:34) [37]

Игорь, я с тобой спорить не буду. Ты всегда всё знаешь лучше всех, больше всех, дальше всех...
А если без сарказма, то
Только обычно информация по подобным заказам загружаются автоматически из внешнего источника или вводится удаленно непосредственно заинтересованным лицом, у которого есть время подумать над введенным, а не ломать клавиатуру, добиваясь неслыханной скорости ввода. Если где-то так, это вовсе не говорит о безусловной правильности производственного процесса :)

Игорь Шевченко © (10.05.07 13:46) [38]

дело не в школьниках. А в стоимости полевого оборудования. Академия наук Узбекистана врядли будет разорвться на мобильные станции. Так что пока сейсмограммы пишуться на бумагу для кардиограмм, а полевые наблюдения на бумагу. И не только в сейсмике.

Но великие программеры живущие в сытой Маскве и Подмосковьи могут себе позволить не вдаваться в иные области науки. Это наш удел, сирых и убогих.

Методы организации добавления записи в таблицу... Найти похожие ветки