Серые кнопки. Изначально неверное решение.

[ta_and]

Предыстория:
В стандартной функциональности Ахарты повсеместно используются "серые" кнопки.
То есть в какой-то момент времени кнопка доступна, а в какой-то момент времени она становится недоступной и пользователь не может на нее нажать.
Казалось бы - о! Как здорово! Пользователю не даем делать то, что ему нельзя!
На самом деле - все совсем не так.
Мне кажется - это абсолютно НЕВЕРНОЕ решение.
Серые кнопки в многопользовательской среде - это полный абсурд!
А теперь обосную свою точку зрения.

Доводы
Почему НЕЛЬЗЯ делать кнопки недоступными

1. Ахарта - многопользовательска среда.
И если эта конкретная кнопка в данный момент на данной форме недоступна, то это НЕ ОЗНАЧАЕТ, что это действие в данный момент времени на данной форме совершить нельзя. Это означает, что в момент, когда открывались текущие данные это действие делать было нельзя. Но через буквально полсекунды после того, как эта кнопка отобразилась недоступной, какой-то другой пользователь сделал действие, которое РАЗРЕШАЕТ действие по данной кнопке. Но текущая форма (а следовательно и пользователь) об этом еще НЕ ЗНАЮТ. В итоге - только после обновления данных становится возможным сделать уже давно доступную операцию.

Еще хуже, если кнопка в момент отображения данных доступна.
На самом деле - какой-то другой пользователь уже мог сделать другую или эту же операцию со своего рабочего места! Но текущая форма (а следовательно и пользователь) об этом еще НЕ ЗНАЮТ. Пользователь радостно жмет на доступную кнопку.... И тут масса вариантов. От корректного отображения ошибки (если программист был хороший) до полного бреда в данных и краха базы.

2. Информативность.
Основное объяснение почему надо сделать недоступную кнопку от постановщиков задачи и конечных пользователей:
"Вот кнопка серая и пользователь сразу видит, что данную операцию делать нельзя."
Даже если не принимать в расчет довод №1 о многопользовательской среде, все равно данное объяснение не выдерживает никакой критики по одной простой причине.

"ПОЧЕМУ нельзя?!"

А ведь данный вопрос постоянно возникает перед пользователем, когда он видит серую кнопку.
Хорошо, если пользователь опытный. Он знает, что разнесенный заказ уже нельзя больше разнести. Тут и тупой сообразит. А что делать, если недоступна кнопка например изменения настроек? Вот она была доступной, и вдруг стала недоступной.
Почему?! И побежал бедный неопытный пользователь к более опытному товарищу.
Более опытный товарищ посмотрел на эту серую кнопку, почесал репу, и сказал "Не знаю". И побежали они оба к консультанту. Консультант посмотрел на эту серую кнопку, почесал репу, и сказал "Не знаю". И побежали они втроем к программисту. Программист поставил точку останова на форме и посмотрел в коде отчего же эта кнопка все таки серая... Ага. Вот почему!!! Все стало ясно и понятно. Все правильно. Она должна быть серой. Все довольны, все смеются.

Всего этого можно было бы легко избежать, если бы кнопка оставалась доступной, но перед началом операции была сделана обязательная проверка на допустимость совершаемых действий. И если вдруг данное действие в данный момент времени запрещено, то пользователю было бы выдано ясное и понятное сообщение ПОЧЕМУ этого делать нельзя. Сразу снимается куча вопросов.

3. Информативность. Пункт два.
Возражение от постановщиков задачи и конечных пользователей:
"Но ведь пользователь сразу хочет видеть что данное действие недопустимо, не нажимая на кнопку!"
Даже если не принимать в расчет довод №1 о многопользовательской среде, все равно, данное требование не удовлетворяется Недоступностью кнопки.
Потому что для того, чтобы увидеть, что данное действие недоступно нужно обязательно сделать текущими просматриваемые данные. Например в гриде выбрать определенную запись. И если нужно просмотреть допустимость действия по ста записям, нужно встать на каждую!! из этих ста записей. Поэтому "сразу" это не аргумент.
Сразу - это выведенная иконка для каждой записи в гриде или информативное дисплейное поле.
Например, если по какой-то записи нужно отображать - есть дочерние документы или их нет, то делать кнопку открытия дочерних документов недоступной - не информативно.
Намного лучше - вывести дисплейную иконку для каждой строки грида, отображающую что документы есть. И можно даже этой иконкой отобразить в каком статусе эти документы.
Подобное, более оптимальное и информативное решение, альтернативное "серой кнопке", можно найти в каждом конкретном случае.

4. Производительность.
Играться с доступностью кнопки – ресурсоемкое занятие.
При каждом действии пользователя, форма должна отслеживать какие данные изменились и делать запрос к базе данных для того, чтобы определить какие кнопки делать недоступными, а какие нет.
Таких запросов может быть очень много (если много кнопок на форме) и эти запросы будут валиться к базе данных ПОСТОЯННО. При каждой смене строки.
Если же продумать более верное решение - например дисплейное поле, то запрос к базе данных будет сделан только для отображаемых в данный момент записей. один раз. может быть несколько запросов, но все равно их будет меньше, чем при постоянной проверки допустимости кнопок.

5. Программируемость.
Для того, чтобы сделать кнопки серыми мы никак не можем обойтись без программного кода на форме.
Программный код на форме - это изначально плохо.
Даже если мы весь код запросов переносим в статические методы на сервер, даже если мы переносим методы анализа в класс... Все равно. Программирование и последующая поддержка формы для программиста усложняется в разы.
К тому же, обычно, код, который делает кнопки недоступными, полностью дублирует (должен дублировать!) код проверки допустимости совершения конкретного действия.
что приводит к дублированию кода и постоянному расхождению в критериях "доступности" кнопки и реальной возможности сделать какое-либо действие.
Для программиста всегда намного проще сделать одну проверку в нужном классе, чем постоянно дергать форму для того, чтобы изменить критерии доступности кнопки.



Вывод
Серые кнопки - ЗЛО.
Все должны это понимать.
Даже если все же принимается решение делать конкретную кнопку недоступной при некоторых критериях, мы должны обязательно принимать во внимания изложенные выше соображения.



ПС
Не смог сдержать крик души.
На каждом проекте - одно и то же!
Серые кнопки... серые кнопки... серые кнопки.
И на каждом проекте приходится с ними долго и упорно сражаться и жить....
Я не призываю полностью отказаться от серых кнопок.
Я не призываю переписать уже имеющийся функционал.
Давайте хоть новую функциональность проектировать грамотно?