при вводе root pw (и других) имеет смысл не активировать кнопку "далее" при различии паролей (плюс выводить где-нить рядом причину -- "passwords do not match"/"пароли не совпадают").
to maintainer
у нас тут несколько другой подход, идентичноть/неидентичность проверяются не на уровне интерфейса, а на уровне модели, там же у нас идут и многие другие проверки. Можно конечно вынести проверку на совпадение в интерфейс, но это будет идеологически неверно с точки зрения архитектуры alterator, по крайней мере текущей архитектуре.
Понимаешшш... это может значить, что модель придётся расширять, но опять же у редхата это было сделано если не в 6.x, то в 7.x. И сейчас сделано практически везде, на что недавно смотрел. Бишь я тебя прекрасно понимаю и диагноз принят, но было бы уместно. :-) PS: кажется, когда-то в devel-conf@ уже нудел на этот счёт...
Не вижу никаких противоречий в том, чтобы сделать это и в интерфейсе тоже. Смена интерфейса, в этом случае, никак не влияет на модель. Т.е. модель делает это сама по себе, а интерфейс сам по себе.
Anton Farygin wrote: > Alexey Voinov wrote: > >Stanislav Ievlev wrote: > >>Ладно, уговорили, будет вам проверка на совпадение в интерфейсе ;) > >>Может идеологически и не верно, зато юзерфрендли ;) > >Полностью идеологически верным решением было бы отправлять > >запрос в модель, там говорить: "да, при таких значениях > >параметров можно переходить на следующий шаг", или: "нифига > >нельзя, тут ещё дописать кой-чего надо", после чего обновлять > >состояние интерфейса. Но это в текущей реализации будет > >работать очччень медленно. :) Что и говорил про модель. Просто плохо помнил твоё описание и оно с тех пор могло триста раз измениться как бы... > Не все так просто. Тут все равно возникает необходимость > хранения состояния на уровне интерфейса. Например - что-то > понастроили, переключились в другую закладку на этом же окне, > опять понастроили, переключаемся обратно - теряется предыдущая > настройка... отправлять это в backend как бы не совсем > правильно - это не готовый результат. Именно. Это, кстати, ещё пачка неповешенных багов по юзабилити, которые было решено пока отложить (хотя бы пока иксы не поднимутся). > Ну или backend должен более тесно взаимодействовать с frontend. > Но для этого нужно значительно ускорить всё, что висит на > bus... и уменьшить количество различного рода форков до > минимума. Вообще в миру это обычно делается чем-то, что висит и обрабатывает запросы. См. FastCGI vs CGI как один из ярких примеров. > В общем - не в этой жизни похоже. Эх... "если вы такие умные, почему ж строем не ходите" -- в смысле про форки и сохранение состояния можно было подумать и год назад над чаем... ну или там за шашлыком. Думал, сами знаете. Ладно, пока look один, можно воткнуть в него, а вот при поползновениях на их размножение придётся думать над выносом вниз. Но оставлять как есть действительно не стоит, когда что-то сделал и это сбросили -- многих раздражает.
Но это в текущей реализации > будет работать очччень медленно. :) Я бы даже уточнил, при текущей архитектуре. Когда есть дополнительные слои, реализованные отдельными процессами в принципе никаких скоростей не будет. Вообще говоря совершенно без разницы не пустят пользователя сразу на следующий шаг, заблокировав кнопку при несовпадении паролей или ему скажут о том что пароли не совпадают потом. Вообще чем дальше идёт дискуссия, тем больше я уверен что так делать не надо: блокировать кнопку и рядом писать причину. 1. Пока пользователь будет вводить пароль пароли и так сами по себе совпадать не будут - зачем ему тогда мазолить глаза надписью что "пароли не совпадают". Естественно, что они не совпадают, он (пользователь) из без нас это будет знать. 2. Более разумный вариант потом рассказать о причине неуспеха, но тут вообще говоря без разницы где это говорить в отдельном диалоге или в том же самом высвечивать какой-либо текст. Отдельный диалог даже лучше - на него невозможно не обратить внимание, в отличие от магически возникающих надписей.
Вроде исправлено?
Кажется, fixed?
reopen
Меня устраивает, спасибо.
