Как такое задизайнить и реализовать?
каждая ячейка представляется в двух классах: класс отображения (отрисовка и перерисовка, ловит события изменения и ввода значений), класс-модель (внутренняя логика, пересчет единиц, валидация и т.д., отправка и обработка сообщений).
над всем этим сидит большой менеджер сообщений, который организует сообщения (доставка по адресату и т. д., bubbling)
+ некоторые кол-во контроллеров, в которых реализована логика между объектами (если изменилось А, то отправить сообщения B и C)
viewA.onChange() -> modelA.valChanged() ->EVENTMANAGER -> modelB.valChanged() -> viewB.redraw()
-> modelC.valChanged() -> viewC.redraw()
-> - какой-то контроллер
modelA.valChanged(obj) {
var res = AJAX(obj);
var newObj = doSmth(res);
new Event(A, 'val changed', newObj);
return newObj;
}
пиши на JSтам в полной схеме расчетов участвуют значения из setting-ов, тащить всю бизнес логику на клиента в js не хочется.
объект row -строка
реагирует на .onChange() на свои ячейки - вызывает .update()
function Row() {
var that = this;
var data;
var init = function (){...};
var serializeData = function(){...};
var postAjax = function(serializedData, callback){...};
var updateView = function(){....};
that.update = function() {
postAjax(that.serializeData(), updateView()) //- AJAX-запрос к серверу с упакованными данными;
// updateView() - колбэк для успешного ответа от сервера
}
init();
updateView();
}
если надо считать агрегатную информацию по строкам (типа total для всех строк) - оберни row в table и событие onChange() просто выталкивай вверх (как в DOM дереве)
Как это сделать наиболее удобно для пользователя?а в чем собственно вопрос? Какой сделать ui, или как такой ui делать?
Какой сделать ui, или как такой ui делать?первое и, если не тривиально, то и второе.
Потом пишешь вьюху, где присутствуют все нужные поля из эксельной таблички, а три последних поля считаешь кейсом.
Если в бд это не отражается, то примерно то же самое, только в объектах.
// Ах да, если ui - то это не к нам, хотя я бы сделал либо дропдаунбокс для флажка, что вводим, и одно поле ввода; либо обнулял остальные из трех последних колонок экселя при попытке юзером ввода чего-либо в одну
Иначе добавить комбу с выбором режима, при смене режима вставлять нужное кол-во текстовых полей для ввода, а расчетные данные выводить в виде простого текста.
Техническую реализацию проще всего делать через ajax, заменяя весь блок целиком, но чтобы фокус не прыгал при замене, то перед заменой запоминать где был фокус и курсор, и затем его восстанавливать.
три поля не могут быть одновременно заданы вручную.не надо лишних ограничений - судя по задачке надо просто при расчетах учитывать последний введеный параметр и пересчитывать каждый раз
т.е. пользователь просто вводит значений в любое из 3х полей - 2 других сразу пересчитываются
кстати, да, при этом ему может быть вообще пофигу, какие он вводил, а какие оказались пересчитанными, может быть это тоже убрать из интерфейса (цветовые обозначения или какие-либо другие).
А как же НФ?
т.е. пользователь просто вводит значений в любое из 3х полей - 2 других сразу пересчитываютсяда, так еще лучше
т.е. пользователь просто вводит значений в любое из 3х полей - 2 других сразу пересчитываютсяпересчитывать два других не всегда требуется, например, если вводится Subtotal, то в Discount(%), DiscountedPrice надо поставить прочерки.
По-видимому, задача сводится к тому как пользователь задает один из трех режимов пересчета.
Исходный вариант. Режим пересчета определяется последним отредактируемым полем. Но что такое отредактируемое поле onChange или потеря фокуса? Потеря фокуса плоха тем, что он может просто TAB-ом пройти поле. С onChange обратная проблема, если сначала ввел 20%, а потом хочет сменить режима на Subtotal (т.е. не хочет видеть цифры в полях Discount(%), DiscountedPrice), но при этом хочет оставить число 400? Один из возможных вариантов его действий такой. Он стирает Discount(%) и переходит в Subtotal. В принципе описанная схема будет работать. Но возникает такая мысль, может сделать схему чуть жёстче – заставлять пользователя стирать для смены режима. На новой форме все поля открыты для редактирования, пользователь вводи значение в одно из них, остальные становятся read only (просто текстом цифры или прочерки). Для смены режима пересчета пользователь должен очистить поле, в которое ввел значение. По всей видимости, смена режима пересчета не очень частый сценарий, пользователь заходит на форму и он знает, что он хочет ввести.
P.S. Еще есть вариант ввести радиобатоны напротив текстовых полей, но нашему менеджеру это не нравится. С ним можно согласиться, довольно громоздко выглядит и еще надо врубиться зачем это.
на read only поля можно повесить тултип типа "для редактирования очистите ххх поле"
а если вместо тултипа сделать рядом с числовым значением небольшую иконку-кнопку с изображением карандаша (Edit), то будет совсем хорошо
Для смены режима пересчета пользователь должен очистить поле, в которое ввел значение.имхо, не эргономично. Пользователь знает в какое поле он хочет ввести число, и визуально представляет где оно находится, а вместо этого его заставляют найти какое-то другое поле и там сначала что-то сделать.
в последнем варианте с иконкой это не требуется, он просто нажимает на иконку Edit
Но при первом показе формы иконок нет, все поля доступны для редактирования
пересчитывать два других не всегда требуется, например, если вводится Subtotal, то в Discount(%), DiscountedPrice надо поставить прочерки.ну так ставь - я просто не понимаю, чего ты мозг ебешь - пересчитывай исходя из последнего редактируемого поля (по onChange), где надо - там ставь прочерки и вообще что угодно
(т.е. не хочет видеть цифры в полях Discount(%), DiscountedPrice)ты уверен, что он именно не хочет - или ты просто усложняешь задачу или пытаешься свою логику применить?
сделай их просто ячейками, при двойном клике - преобразовывай в инпут - все логично и понятно
+ можешь сделать live изменения (onKeyPress) - но будет большой оверхэд по AJAX запросам, т.к. логику в JS ты переносить не хочешь
объясни зачем ты хочешь ввести в в систему лишнюю жесткость?
сделай тогда лучше в таком виде:
табличка в которой все легко редактируется (как я выше описывал), но есть кнопки UNDO, REDO, SAVE, REVERT
соот-но все изменения передаются не в live-режиме, а после нажатия кнопки SAVE, до этого пользователь сколько угодно может корячить табличку и подбирать удобные ему значения, при возможности сбрасываясь до предыдущих сохраненных
ну так ставь - я просто не понимаю, чего ты мозг ебешь - пересчитывай исходя из последнего редактируемого поля (по onChange), где надо - там ставь прочерки и вообще что угодно
я всего лишь уточнил требования, мне показалось, что они важны для твоего понимания, если не важны, то, имхо, все равно это не повод материться
ты уверен, что он именно не хочет - или ты просто усложняешь задачу или пытаешься свою логику применить?здесь всё на грани, но я стараюсь смотреть критично (в частности и на свои решения). Это “желание” пользователя я вывожу из того, что на экране должно быть то же самое как если он сразу начал вводить в Subtotal.
Да, live не подходит из-за тормозов при вводе (тормоза из-за раутнд трипа на сервер).
сделай их просто ячейками, при двойном клике - преобразовывай в инпут - все логично и понятно
Что есть ячейка? На форме либо текствокс либо просто текст. Ячейка это текст в рамке?
Двойной клик можно рассмотреть как вариант (так Excel работает), но это снижает эргономичность (освояемость). Если принять во внимание, что вначале иконок нет (они появляются только после первого ввода), а смена режима пересчета редкий сценарий. Таким образом, нацеливаться на иконку это редкий сценарий.
табличка в которой все легко редактируется (как я выше описывал), но есть кнопки UNDO, REDO, SAVE, REVERT
соот-но все изменения передаются не в live-режиме, а после нажатия кнопки SAVE, до этого пользователь сколько угодно может корячить табличку и подбирать удобные ему значения, при возможности сбрасываясь до предыдущих сохраненных
в это пользователи долго врубаться будут. По эргономичности это проигрывает edit-иконкам.
объясни зачем ты хочешь ввести в в систему лишнюю жесткость?
в этом случае на экране видно, что является исходным (вводимым) значением, а что расчётным. Дополнительная ясность на экране это хорошо (что мы при этом теряем, надо сравнивать).
в этом случае на экране видно, что является исходным (вводимым) значениемэто действительно нужно показывать?
просто для меня нет разницы из чего получается, к примеру, 0.2 - это или 20% или 200/1000 - в любом случаем, меня не сильно интересует каким образом я получил эти значения.
Что есть ячейка?
на скриншоте я вижу таблицу, ячейка таблицы - это какое-то значение, которое отделено от другого
в это пользователи долго врубаться будут. По эргономичности это проигрывает edit-иконкам.
это хорошо знакомый пользователь паттерн поведения файлов, поизменял - сохранил, или откатил на исходное
Оставить комментарий
6yrop
На веб странице расположены следующие поля:Quantity
Price
Discount(%)
DiscountedPrice
Subtotal
Последние три поля могут быть либо введены вручную, либо рассчитаны на основе других. Вот перечислены возможные сценарии, желтым отмечены вводимые значения, зеленым расчетные:
На форме отображается одна строчка из гриды.
Расчеты хочется выполнять на сервере.
Как это сделать наиболее удобно для пользователя?