Заблокировать menuItemButton если запись не выбрана

[gl00mie]

Цитата:

Сообщение от Vadik

Мне хотелось бы, чтобы эта функциональность работала бы откуда бы ее ни вызывали и не ломалась от того, что кто-то что-то на форме добавит, переместит или перекроет (или забудет перекрыть). Так же хотелось бы избежать ненужного неконтролируемого трафика (иногда - платного) между AOS-ом и клиентом, равно как и между клиентом и терминальным сервером (чего в случае перекрытого display метода не избежать).

К слову, да, тут как-то упустили то, что запрет выполнения какой-то функции при отсутствии записей должен быть в первую очередь зашит в бизнес-логику, а уже во вторую или десятую - в презентационную. Потому что если у вас возможность выполнения какого-то действия будет зависеть от доступности кнопки, то мне вас искренне жаль: завтра вместо форм в толстом клиенте начнется использование business connector'а, которому пофиг на все эти кнопки и который в теории может дергать ваш код с совершенно произвольными параметрами; послезавтра начнется использование EP, и какой-нить умник с помощью локальной прокси научится подсовывать своему браузеру странички, где кнопки ни разу не заблокированы... С этой точки зрения проверка записи в main() или validate() вызываемого класса (при том что запись выбирается по ключу, а не берется табличный буфер с формы - во избежание срабатывания dynalink в самый неподходящий момент), может, не столь привлекательна для конечного пользователя, но зато наиболее близка к уровню бизнес-логики, которому должно быть безразлично, откуда он дергается: с формы ли, со странички ли портала или из другого приложения посредством business connector'а.

[sukhanchik]

У запрета доступности кнопки при всей скажем так неудобности (=дороговизне) реализации есть 2 существенных плюса:
- "МарьИванне станет хорошо", т.е. условно "непродвинутому" пользователю будет понятнее. Про это уже говорил Vadik. Хоть платит и не МарьИванна - но плательщику важно, чтобы смена системы не привела к необходимости увеличить расходы на содержание персонала (ну или он стремится минимизировать сие увеличение).
- будет облегчение на этапе обучения как новому функционалу так и новых сотрудников.

Соответственно - клиент, условно переплачивая за излишнее программирование, чтобы программист потратил лишних полчаса (а при грамотном подходе - больше и не требуется) - экономит впоследствии на обучении (МарьИванна быстрее обучится и новая НатальФедоровна тоже быстрее поймет) и на текущей работе (лишняя защита "от дурака" для низкоквалифицированных = дешевых пользователей). При этом (важно), что экономится двойное (пусть и неравное) время - как обучающего, так и обучаемого. Плюс - снижается риск сложности освоения системы (=экономия на времени=деньгах) в случае, если "все те кто знали это - давно уже ушли". Кстати - это касается как пользователей, так и программистов / администраторов / службы сопровождения / нового партнера.

При этом никто не отменяет необходимость встраивание защиты в бизнес-логику на случай всяких коннекторов, порталов и прочих приблуд.

Единственное - что - в этом случае - нужно "не перегнуть палку". Т.е. не нужно кидаться сломя голову все переделывать на "недоступную кнопку", равно как и переделывать на "ошибку после нажатия кнопки". Причем "неприкосновенность ядра" актуальна только для специалистов - которым привычнее (=быстрее разобраться) штатное поведение всех кнопок. В случае же каких новых кнопок - специалисту и пользователю одинаково нужно изучать их поведение.

Со своей стороны получилось так - что мне (как программисту) потребовалось изучить некоторое приложение (изрядно уже до меня модифицированное) в АХ, которое было построено по принципу - "недоступная кнопка" и "максимальное заполнение полей по умолчанию при условии единственного варианта заполнения". Я в нем разобрался достаточно быстро только потому, что у меня не было возможности "свернуть с истинного пути".
Вывод: Было сэкономлено мое время и время моего обучающего, а это деньги.

К сожалению - нельзя точно оценить в деньгах и сравнить экономию на обучение и дополнительное программирование по запрету кнопки.

Однако - доля смысла в приведении интерфейса под стиль "Джобса и Ко" (а точнее - под стиль, в котором легче проводится обучение) есть.