Bug 6504 - [FR] при вводе паролей проверять идентичность [...]
: [FR] при вводе паролей проверять идентичность [...]
Status: CLOSED WORKSFORME
: Sisyphus
(All bugs in Sisyphus/install3)
: unstable
: all Linux
: P2 normal
Assigned To:
:
:
:
:
:
  Show dependency tree
 
Reported: 2005-04-13 14:17 by
Modified: 2007-11-10 15:51 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2005-04-13 14:17:27
при вводе root pw (и других) имеет смысл не активировать кнопку "далее" при
различии паролей (плюс выводить где-нить рядом причину -- "passwords do not
match"/"пароли не совпадают").
------- Comment #1 From 2005-04-13 17:03:26 -------
to maintainer 
------- Comment #2 From 2005-04-13 18:36:05 -------
у нас тут несколько другой подход, идентичноть/неидентичность проверяются не на
уровне интерфейса, а на уровне модели, там же у нас идут и многие другие
проверки.  Можно конечно вынести проверку на совпадение в интерфейс, но это
будет идеологически неверно с точки зрения архитектуры alterator, по крайней
мере текущей архитектуре.
------- Comment #3 From 2005-04-13 18:46:07 -------
Понимаешшш... это может значить, что модель придётся расширять, но опять же у
редхата это было сделано если не в 6.x, то в 7.x.  И сейчас сделано практически
везде, на что недавно смотрел.

Бишь я тебя прекрасно понимаю и диагноз принят, но было бы уместно. :-)

PS: кажется, когда-то в devel-conf@ уже нудел на этот счёт...
------- Comment #4 From 2005-04-13 20:00:59 -------
Не вижу никаких противоречий в том, чтобы сделать это и в интерфейсе тоже.
Смена
интерфейса, в этом случае, никак не влияет на модель. Т.е. модель делает это
сама по себе, а интерфейс сам по себе.
------- Comment #5 From 2005-04-15 09:36:43 -------
Anton Farygin wrote:
> Alexey Voinov wrote:
> >Stanislav Ievlev wrote:
> >>Ладно, уговорили, будет вам проверка на совпадение в интерфейсе ;)
> >>Может идеологически и не верно, зато юзерфрендли ;)
> >Полностью идеологически верным решением было бы отправлять
> >запрос в модель, там говорить: "да, при таких значениях
> >параметров можно переходить на следующий шаг", или: "нифига
> >нельзя, тут ещё дописать кой-чего надо", после чего обновлять
> >состояние интерфейса. Но это в текущей реализации будет
> >работать очччень медленно. :)

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

> Не все так просто. Тут все равно возникает необходимость
> хранения состояния на уровне интерфейса. Например - что-то
> понастроили, переключились в другую закладку на этом же окне,
> опять понастроили, переключаемся обратно - теряется предыдущая
> настройка... отправлять это в backend как бы не совсем
> правильно - это не готовый результат.

Именно.  Это, кстати, ещё пачка неповешенных багов по юзабилити,
которые было решено пока отложить (хотя бы пока иксы не
поднимутся).

> Ну или backend должен более тесно взаимодействовать с frontend.
> Но для этого нужно значительно ускорить всё, что висит на
> bus... и уменьшить количество различного рода форков до
> минимума.

Вообще в миру это обычно делается чем-то, что висит и обрабатывает
запросы.  См. FastCGI vs CGI как один из ярких примеров.

> В общем - не в этой жизни похоже.

Эх... "если вы такие умные, почему ж строем не ходите" --
в смысле про форки и сохранение состояния можно было подумать и
год назад над чаем... ну или там за шашлыком.  Думал, сами знаете.

Ладно, пока look один, можно воткнуть в него, а вот при
поползновениях на их размножение придётся думать над выносом
вниз.  Но оставлять как есть действительно не стоит, когда что-то
сделал и это сбросили -- многих раздражает.
------- Comment #6 From 2005-04-18 11:34:54 -------
 Но это в текущей реализации
> будет работать очччень медленно. :)
Я бы даже уточнил, при текущей архитектуре. Когда есть дополнительные
слои, реализованные отдельными процессами в принципе никаких скоростей не
будет.
 
Вообще говоря совершенно без разницы не пустят пользователя сразу на
следующий шаг, заблокировав кнопку при несовпадении паролей или ему скажут
о том что пароли не совпадают потом.
 
Вообще чем дальше идёт дискуссия, тем больше я уверен что так делать не
надо: блокировать кнопку и рядом писать причину.
 
1. Пока пользователь будет вводить пароль пароли и так сами по себе
совпадать не будут - зачем ему тогда мазолить глаза надписью что "пароли не
совпадают". Естественно, что они не совпадают, он (пользователь) из без
нас это будет знать.
 
2. Более разумный вариант потом рассказать о причине неуспеха, но тут
вообще говоря без разницы где это говорить в отдельном диалоге или в том
же самом высвечивать какой-либо текст. Отдельный диалог даже лучше - на
него невозможно не обратить внимание, в отличие от магически возникающих
надписей.
 
------- Comment #7 From 2006-02-17 18:43:02 -------
Вроде исправлено?
------- Comment #8 From 2007-02-25 00:58:50 -------
Кажется, fixed?
------- Comment #9 From 2007-11-10 15:50:38 -------
reopen
------- Comment #10 From 2007-11-10 15:51:03 -------
Меня устраивает, спасибо.