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

Меня устраивает, спасибо.