Python-сообщество

securelord
Очень просто - сканер в разрез с клавиатурой… сосканировал в поле формы, нажал кнопочку проверки к примеру

зачем использовать обычный сканер для считывания штрих-кода с бумажки?
специальный считыватель и проще в эксплуатации и дешевле

так я о сканере штрих-кода и писал

Хотя у меня вызывает сомнение удобство web интерфейса в рабочем месте оператора.
В дремучем 1999 такое делал. Девочки вешались.
А потом таки переделывал на толстого клиента. Скорость обслуживания оператором входящего звонка увеличилась раза в полтора в среднем.
Второй раз наступать на грабли не хочу до сих пор.

Сейчас часть нашей разработки включает рабочее место кассира. Оно - на wxPython.
А вот для отчетов и админки веб очень хорошо подходит.

Отредактировано (Июнь 14, 2007 19:20:03)

Андрей Светлов
Хотя у меня вызывает сомнение удобство web интерфейса в рабочем месте оператора.

веб хорош в данном случае для отчетов, а вот не понятно как технически веб-страничка проекта считывает данные с сканера штрих-кода?

Андрей Светлов
А потом таки переделывал на толстого клиента.

согласен - здесь лучше организовать приложение cервер-клиент XML-RPC

XMLRPC - именно. Или SOAP. Или любой другой вариант.

Повторяю. Сканер штрихкода втыкается в USB и распознается как USB клавиатура. Когда он видит штрихкод, то эмулирует нажатие клавиш, т.е. печатает этот штрихкод и ентер в конце. И все. И печататься будет в текущем поле ввода, где стоит курсор. Это браузер, ворд или твоя программа - не имеет значения.

Отредактировано (Июнь 14, 2007 18:53:09)

Андрей Светлов
Хотя у меня вызывает сомнение удобство web интерфейса в рабочем месте оператора.
В дремучем 1999 такое делал. Девочки вешались.

Можно узнать из-за чего? Насколько я понимаю, web-технологии с того бородатого года значительно подросли.

Преамбула. Люблю веб и те новшества, которые в нем возникли. Но применимы они не всегда.

С того бородатого года появился только AJAX (поправьте меня, если что не так).
На нем можно многое сделать, но не все. Это же делается и на толстом клиенте. Причем легче и быстрее. А еще можно сделать гораздо гибче. User graphics interface api куда шире, чем модель javascript для браузера (поправьте меня опять, если и это не так).
Скорость разработки такого толстого клиетна гораздо выше, чем скорость создания отличного сайта с AJAX наворотами. Гугль показывает прекрасную альтернативу, но у них задача “быть для всех” и они готовы платить за это временем разработки.
Время разработки существенно влияет на ее стоимость (здесь, думаю, никто поправлять не захочет).

Теперь переходим к задаче. Есть сеть рабочих мест. Софт диктуется владельцем. Что прикажет - то и будут юзать. Несогласных нет и быть не может.

Стоимость поддержки корпоративных клиентов.
- Чем веб вариант хорош - бесплатен. Только нужно будет объяснить нововведения сотрудникам по телефону или при выезде на место :)
- То же прийдется делать при толстом клиенте.
Стоимость развертки.
- Мы уже давно научились делать хорошие инсталляторы для наших питон проектов. Которые нужно всего лишь запустить, и все заработает. В случае корпоративного продукта все даже изрядно проще и не надо указывать proxy и прочую чепуху. Или, если таки надо указывать, легко автоматически слизать настройки с IE, Opera, Firefox etc. Или сделать конфигуратор. Все равно их прийдется где-то вводить. Обмениваться информацией можно и по HTTP (XMLRPC, SOAP, etc). Мы используем свой вариант Python-to-Python протокола over HTTP - он меньше кушает трафика. AJAX (я уже не говорю о прочем) на порядок прожорливей.

И, наконец. Когда мы делали своего кассира, поставили себе цель: минимальное количество действий/нажимаемых кнопок. Удалость провести весь цикл на numpad клавиатуре. Без кнопочек вправо-влево и БЕЗ МЫШКИ. Продуктивность оцените сами. И с минимумом нажатий на кнопки. Я не уверен, что то же самое возможно сделать через веб для тех же Opera, Firefox и IE одновременно. И не уверен, что это будет быстрее/дешевле.

Да, обязательный постскриптум. Очень люблю интернет. Люблю нововведения, которые появились с “бородатого года” и ими пользуюсь. Убежден, что они не всегда применимы (3D графика, ха!) и убежден, что не всегда оправданы (смотри выше).

Отредактировано (Июнь 15, 2007 15:42:00)

Андрей Светлов
Мы используем свой вариант Python-to-Python протокола over HTTP - он меньше кушает трафика.

если можно расскажи пару слов про это.

Я бы, как и Андрей Светлов, тоже порекомендовал толстого клиента.

Андрей Светлов: благодарю за развёрнутый ответ. Спорить мне не с чем, так как подобных “серьёзных” проектов за плечами нет.

Андрей Светлов
С того бородатого года появился только AJAX (поправьте меня, если что не так).

Значительно расширилась сервисная часть web'а. А вместе с ней и инструменты, эти сервисы предоставляющие. Думаю, сейчас javascript'овые библиотеки умеют значительно больше, чем они же в 1999ом. Поправите?

Скорость разработки такого толстого клиетна гораздо ниже, чем скорость создания отличного сайта с AJAX наворотами.

Вы хотели сказать “выше” ? TG, Pylons, RoR с их продуманными AJAX частично могут решить эту проблему. Думаю, в будущем они решат её полностью.

Мы используем свой вариант Python-to-Python протокола over HTTP - он меньше кушает трафика.

Присоединяюсь к bialix. Можно поподробнее про этот протокол? Если он не военная тайна, конечно.

Удалость провести весь цикл на numpad клавиатуре. Без кнопочек вправо-влево и БЕЗ МЫШКИ. Продуктивность оцените сами. И с минимумом нажатий на кнопки. Я не уверен, что то же самое возможно сделать через веб для тех же Opera, Firefox и IE одновременно.

С горячими клавишами в web'е всё так плохо? Сам думаю, смогу ли реализовать управление исключительно с клавиатуры. Без этого пункта операторы системы и впрямь могут прибегнуть к коллективному сюициду.