24.12.2010, 11:36 | #21 |
Гость
|
Цитата:
У него ощущение фэншуйности происходящего и заботы со стороны системы возникает. А ругательные окошечки никто не любит. |
|
24.12.2010, 11:37 | #22 |
Участник
|
Цитата:
Цитата:
Сообщение от S.Kuskov
нужно ловить манипуляции с источником данных, прекрыть и executeQuery() и delete(), но это не спортивно . Вот было бы прекрасно если бы такое поведение кнопки регулировалось каким-нибудь стандартным свойством. Мне кажется в этом будет смысл. На мой взгляд, текущее положение вещей создаёт какую-никакую но всё-таки потенциальная угрозу ошибки, вдруг в каком-нибудь месте системы нет соответствующей проверки в коде.
Последний раз редактировалось S.Kuskov; 24.12.2010 в 11:44. |
|
24.12.2010, 11:56 | #23 |
Гость
|
А этот контрол нужно по всем закладкам рассовывать?
Если пользователь наложит фильтр, возвращающий пустой набор данных, находясь на закладке, где нет этого контрола, то display-методу по идее не будет причины быть вызванным? |
|
24.12.2010, 12:34 | #24 |
Участник
|
Вспомогательный display-контрол лежит вне вкладок, в корне дизайна. Он не связан с конкретным исочником и реагирует на любое изменение формы
|
|
|
За это сообщение автора поблагодарили: titov (1). |
24.12.2010, 17:58 | #25 |
Участник
|
S.Kuskov - спасибо за верные пояснения - все именно так.
Немного добавлю. Форма может и не иметь источник данных (контролы table,list), тогда перечень методов перехвата резко возрастает. В целом все методы, которые мы хотим перехватить вызывают метод перерисовки формы - вот она ключевая точка, но попасть туда можно только через дисплей метод (или по таймеру крутить свой метод - это второе более плохое решение, так как есть время, когда пользователь может успеть нажать кнопку). Итого - приходиться вот так "троянски" влезать туда, куда не пустили. Насчет сообщений и фэншуйности - почему то поля с запретом редактирования сразу запрещают работу, а не сообщают потом, что "было оказываеться нельзя". Это даже не обсуждается. По кнопкам же вопрос возникает. Потому, что большинство отдельных кнопок имеют такое поведение и считается, что так верно. Не так! Пример из самой Аксапты: пользователь не сможет разнести отгруженный заказ, так как кнопки не активны - там они активируются при нажатии на MenuButton - логика блокировки присутствует. Разница в чем? При отдельной кнопке просто возникает технический момент поиска метода, подобного MenuButton.clicked(), но не на конкретное нажатие, а на действия на форме, изменяющих блокировку. Набор действий (методов) в каждом случае разный, разнообразный и при этом плохо! контролируется программистом - вот причина отказа от блокирования - лучше сообщение, чем непонятные мерцания. А по логике надо сделать "аналогично" форме заказов. |
|
24.12.2010, 19:34 | #26 |
Модератор
|
Цитата:
Пользователю приятно, когда система ведет себя как хочет S.Kuskov.
У него ощущение фэншуйности происходящего и заботы со стороны системы возникает. А ругательные окошечки никто не любит Я рассуждаю с точки зрения разработчика на стороне партнера или вендора, от которого требуется а) относительно быстро (читай - недорого) и б) надежно (лучше - гарантированно) решить простую задачу. Быстро - потому что реально сложных и нужных "уже вчера" задач и так хватает. Недорого - потому что платить за мои экзерсисы клиент как правило не хочет и постоянно норовит продемонстрировать, что понимает, сколько стоит "добавить поле в таблицу" и "добавить кнопку на форму" (пусть даже переделывать за ним дороже чем сделать самому). С точки зрения фэншуйности я вообще могу быть апологетом дизайна пользовательских интерфейсов от Джобса & Co, но работаю в том, что выдали и не жужжу Цитата:
Насчет сообщений и фэншуйности - почему то поля с запретом редактирования сразу запрещают работу, а не сообщают потом, что "было оказываеться нельзя". Это даже не обсуждается
Цитата:
Пример из самой Аксапты: пользователь не сможет разнести отгруженный заказ, так как кнопки не активны - там они активируются при нажатии на MenuButton - логика блокировки присутствует..
.. А по логике надо сделать "аналогично" форме заказов И напоследок относительно "надежно". Мне хотелось бы, чтобы эта функциональность работала бы откуда бы ее ни вызывали и не ломалась от того, что кто-то что-то на форме добавит, переместит или перекроет (или забудет перекрыть). Так же хотелось бы избежать ненужного неконтролируемого трафика (иногда - платного) между AOS-ом и клиентом, равно как и между клиентом и терминальным сервером (чего в случае перекрытого display метода не избежать). В общем, работая на партнере хочется "быстро, недорого, надежно". Я понимаю, при работе "на клиенте" критерии могут меняться на, например, "чтобы МарьИванне стало хорошо". Это нормально, если МарьИванна платит. Главное, чтобы понимала - сколько и за что
__________________
-ТСЯ или -ТЬСЯ ? |
|
|
За это сообщение автора поблагодарили: gl00mie (2), S.Kuskov (1). |
25.12.2010, 21:44 | #27 |
Участник
|
Цитата:
Сообщение от Vadik
Мне хотелось бы, чтобы эта функциональность работала бы откуда бы ее ни вызывали и не ломалась от того, что кто-то что-то на форме добавит, переместит или перекроет (или забудет перекрыть). Так же хотелось бы избежать ненужного неконтролируемого трафика (иногда - платного) между AOS-ом и клиентом, равно как и между клиентом и терминальным сервером (чего в случае перекрытого display метода не избежать).
|
|
25.12.2010, 22:59 | #28 |
Administrator
|
У запрета доступности кнопки при всей скажем так неудобности (=дороговизне) реализации есть 2 существенных плюса:
- "МарьИванне станет хорошо", т.е. условно "непродвинутому" пользователю будет понятнее. Про это уже говорил Vadik. Хоть платит и не МарьИванна - но плательщику важно, чтобы смена системы не привела к необходимости увеличить расходы на содержание персонала (ну или он стремится минимизировать сие увеличение). - будет облегчение на этапе обучения как новому функционалу так и новых сотрудников. Соответственно - клиент, условно переплачивая за излишнее программирование, чтобы программист потратил лишних полчаса (а при грамотном подходе - больше и не требуется) - экономит впоследствии на обучении (МарьИванна быстрее обучится и новая НатальФедоровна тоже быстрее поймет) и на текущей работе (лишняя защита "от дурака" для низкоквалифицированных = дешевых пользователей). При этом (важно), что экономится двойное (пусть и неравное) время - как обучающего, так и обучаемого. Плюс - снижается риск сложности освоения системы (=экономия на времени=деньгах) в случае, если "все те кто знали это - давно уже ушли". Кстати - это касается как пользователей, так и программистов / администраторов / службы сопровождения / нового партнера. При этом никто не отменяет необходимость встраивание защиты в бизнес-логику на случай всяких коннекторов, порталов и прочих приблуд. Единственное - что - в этом случае - нужно "не перегнуть палку". Т.е. не нужно кидаться сломя голову все переделывать на "недоступную кнопку", равно как и переделывать на "ошибку после нажатия кнопки". Причем "неприкосновенность ядра" актуальна только для специалистов - которым привычнее (=быстрее разобраться) штатное поведение всех кнопок. В случае же каких новых кнопок - специалисту и пользователю одинаково нужно изучать их поведение. Со своей стороны получилось так - что мне (как программисту) потребовалось изучить некоторое приложение (изрядно уже до меня модифицированное) в АХ, которое было построено по принципу - "недоступная кнопка" и "максимальное заполнение полей по умолчанию при условии единственного варианта заполнения". Я в нем разобрался достаточно быстро только потому, что у меня не было возможности "свернуть с истинного пути". Вывод: Было сэкономлено мое время и время моего обучающего, а это деньги. К сожалению - нельзя точно оценить в деньгах и сравнить экономию на обучение и дополнительное программирование по запрету кнопки. Однако - доля смысла в приведении интерфейса под стиль "Джобса и Ко" (а точнее - под стиль, в котором легче проводится обучение) есть.
__________________
Возможно сделать все. Вопрос времени Последний раз редактировалось sukhanchik; 25.12.2010 в 23:29. |
|
25.12.2010, 23:15 | #29 |
Administrator
|
Заодно сразу предвосхищу любителей фразы "А вот потом у вас все это вылезет при апгрейде на следующую версию".
Любая следующая версия (если в ней только конечно не пару запятых поставлено) предполагает фактически перевнедрение. Нет смысла переходить (условно) с 4-ки на 2009-ю, сменив при этом только exe-шник (ну конечно - если нет чисто технологических ограничений, которые снимаются новым exe-шником). Нужно заново переосмыслять процессы, удалять лишнюю функциональность, которая уже появилась в стандарте и т.д. А учитывая как сейчас меняются версии - можно говорить смело - апгрейда не будет. Будет абсолютно новая версия с переобучением пользователей (что тоже деньги). Т.е. вывод: нет смысла "закладываться на апгрейд", если все равно потом все переосмысливать (=переделывать) с нуля (ну или - скажем так - экономически необоснованно закладываться). PS. Обсуждение апгрейдов плз вести в отдельной ветке. Здесь данный пост предназначен исключительно для понимания потенциальных затрат, понесенных на способ запрета к какой-то функциональности
__________________
Возможно сделать все. Вопрос времени |
|
26.12.2010, 19:02 | #30 |
Участник
|
Проверки в коде - это хорошо, это правильно, без них не обойтись, это даже не обсуждается. Ещё раз процетирую себя
Цитата:
Вопрос, почему в системе этого не предусмотрено? Много ли смысла в передаче пустого курсор из формы (нормальной аксаптовской формы) в код? Т.е. создавая menuItemButton и связывая его с конкретным источником данных, разве мы не подразумеваем использование этой кнопки только в контексте какой-то (одной или нескольких в случае мультиселекта) записи? P.S.: Cам я несколько раз использовал возможность передачи пустого курсора в различных целях. Например, для получения ссылки на временую таблицу (в результате обработки в неё добавлялись записи), либо для доступа через полученный курсор к связанному с ним источнику данных (в этом случае вообще было не важно есть ли в курсоре данные или нет). Но не думаю что, использовать для этого args.record() оправдано, в таких случаях вполне можно обойтись и без него. И честно говоря в первый раз был удивлён когда данная комбинация сработала. Не было это... интуитивно понятным что ли. |
|
26.12.2010, 19:21 | #31 |
Administrator
|
Цитата:
Сообщение от S.Kuskov
Вопрос, почему в системе этого не предусмотрено? Много ли смысла в передаче пустого курсор из формы (нормальной аксаптовской формы) в код? Т.е. создавая menuItemButton и связывая его с конкретным источником данных, разве мы не подразумеваем использование этой кнопки только в контексте какой-то (одной или нескольких в случае мультиселекта) записи?
__________________
Возможно сделать все. Вопрос времени |
|
26.12.2010, 20:17 | #32 |
Участник
|
Цитата:
Сообщение от S.Kuskov
Много ли смысла в передаче пустого курсор из формы (нормальной аксаптовской формы) в код? Т.е. создавая menuItemButton и связывая его с конкретным источником данных, разве мы не подразумеваем использование этой кнопки только в контексте какой-то (одной или нескольких в случае мультиселекта) записи?
|
|
|
Опции темы | Поиск в этой теме |
Опции просмотра | |
|