Асинхронный обмен данными с JavaScript (и не только) без потерь

0. Александр Быков (Alxby) 192 25.12.16 21:28 Сейчас в теме
Все больше и больше появляется разработок с использованием JavaScript в формах 1С. Вместе с тем достаточно интересным является вопрос передачи данных между скриптом JavaScript и программным модулем 1С. Не претендуя на оригинальность, хочу предложить несложный и практичный механизм передачи данных с использованием очереди.

Перейти к публикации

Комментарии
1. Виталий Чебан (VitaliyCeban) 257 26.12.16 10:25 Сейчас в теме
Учитывая что событие ПриНажатии может быть пропущено, и оно могло быть последним (не поможет обработка предыдущих событий при следующем ПриНажатии, так как его не будет), то относительная гарантия доставки, в итоге, достигается исключительно за счет следующего кода?
&НаКлиенте
Процедура ПриОткрытии(Отказ)
	ПодключитьОбработчикОжидания("ПолучитьИОбработатьДанные",1);
КонецПроцедуры

Относительная, потому что форма может быть закрыта до очередного срабатывания таймера, впрочем, это я уже утрирую )

В любом случае, решение интересное, и существенно лучше его отсутствия, спасибо.
2. Игорь Никик (igo1) 144 26.12.16 13:28 Сейчас в теме
вообще вот пример как работать без обработчика ожидания, можно просто вызвать событие "нажатие", и передать туда данные

http://infostart.ru/public/338126/
3. Виталий Чебан (VitaliyCeban) 257 26.12.16 13:45 Сейчас в теме
(2) Прочитайте более внимательно начало этой публикации.
можно просто вызвать
оно то можно, только есть ненулевая вероятность что в 1С событие ПриНажатии вызвано НЕ будет.
Эту проблему и призвана решить данная публикация.
4. Александр Быков (Alxby) 192 26.12.16 13:48 Сейчас в теме
(3) Спасибо, опередили с ответом:)
5. Александр Быков (Alxby) 192 26.12.16 13:56 Сейчас в теме
(1) Да, при закрытии формы мы можем потерять последние события. Но нам никто не мешает перед закрытием формы их все-таки принудительно получить. К тому же, как мне кажется, основное применение JavaScript - визуальные компоненты интерфейса, данные которых вряд ли нужны после закрытия формы.
6. Сан Саныч (herfis) 117 26.12.16 15:50 Сейчас в теме
"события на вебстранице возникают асинхронно, форма 1С, в общем случае, может какие-то из виртуальных кликов пропустить"
Поясните. По какой причине 1С может пропустить клики. И в каких случаях. Где можно об этом почитать в подробностях.
В документации по "ПриНажатии" ничего такого нет. Т.е. предполагается, что ловиться должны все события.
"события на вебстранице возникают асинхронно" - ну и что с того?
7. Сан Саныч (herfis) 117 26.12.16 15:55 Сейчас в теме
В общем, если пропуски в самом деле происходят, то это недоработка разработчиков 1С. Это они должны были организовывать и обслуживать очереди обрабатываемых событий, если уж задекларировали механизм получения событий от поля HTML документа.
Просто хочется убедиться, что проблема в самом деле существует. Я на самом деле далек от темы, просто интересно.
8. Виталий Чебан (VitaliyCeban) 257 26.12.16 16:45 Сейчас в теме
(7) Поинтересуйтесь у http://infostart.ru/profile/52749/
Самому не приходило сталкиваться с проблемой, но не доверять Евгению, учитывая созданные им решения, у меня оснований нет.
9. Александр Быков (Alxby) 192 26.12.16 16:58 Сейчас в теме
(7) Как бы то ни было, основной целью написания статьи было не решение конкретной проблемы, указанной в примере, а описание способа решения подобных ей проблем, не обязательно связанных с взаимодействием с JavaScript.
10. Сан Саныч (herfis) 117 26.12.16 17:04 Сейчас в теме
(8) ИМХО, если 1С не делает пропусков, скажем, при нескольких событиях HTML с интервалом 1ms, когда в 1С каждое обрабатывается к примеру 5ms (т.е. какая-то очередь все-таки есть), то для большинства практических задач нет смысла обслуживать свою очередь событий. Когда возникнет практическая задача - поставлю эксперимент, раз тут занимаются решением проблем о которых знают по-наслышке.
Задачи Евгения, насколько я понимаю, достаточно специфичны.
11. Сан Саныч (herfis) 117 26.12.16 17:29 Сейчас в теме
(9) Соглашусь. Статью плюсанул.
Сначала зацепился за то, что queueHead пишется из двух процессов (при сбросе очереди), но получается что сброс невозможен одновременно с обработкой события в 1С. Остроумное решение проблемы мьютексов при условии частого обнуления очереди.
12. Александр Быков (Alxby) 192 26.12.16 21:18 Сейчас в теме
(11)Здесь нелишним будет упомянуть, что в JavaScript оператор присваивания имеет ассоциативность справа налево, и
queueHead = queueTail = -1;
эквивалентно
queueTail = -1;
queueHead = -1;
что гарантирует: в процессе обнуления queueHead будет не меньше queueTail и чтение из очереди невозможно.
13. Игорь Никик (igo1) 144 27.12.16 15:20 Сейчас в теме
(3) не встречал таких проблем с пропуском нажатий, но в таком случае я бы решал задачу немного иначе, реализовав гарантированную доставку.

14. Александр Быков (Alxby) 192 27.12.16 16:12 Сейчас в теме
(13) У меня тоже была идея реализовать механизм, похожий на работу TCP (правда для решения другой задачи). Может быть напишете статью о своем варианте?
15. Сан Саныч (herfis) 117 27.12.16 16:29 Сейчас в теме
(13) Каким именно образом и чем он лучше? Статья ведь как раз и рассматривает вариант реализации гарантированной доставки.
16. Петр Базелюк (pbazeliuk) 1284 27.12.16 17:46 Сейчас в теме
(15) Термин "гарантированная доставки" здесь не применим. Объекты жестко связаны, они не могут отдельно работать друг от друга, нет восстановления состояния, например, после падения кластера 1С.

В этом случае, решена проблема пропускания "кликов".

17. Сан Саныч (herfis) 117 27.12.16 18:23 Сейчас в теме
(16) Вы пытаетесь сказать, что под термин "гарантированная доставка" подходят только внешние сервисы очередей? Не думаю, что в (13) именно это подразумевалось :)
В нашем случае "гарантированность" имеет смысл только в рамках жизненного цикла формы.
18. Петр Базелюк (pbazeliuk) 1284 28.12.16 10:39 Сейчас в теме
(17) Сервис очередей не упоминал вроде как. Термин "гарантированная доставка" не должен зависеть от контекста и он не применим точно здесь. Правильней назвать это "fire-and-forget".
19. Игорь Никик (igo1) 144 28.12.16 12:35 Сейчас в теме
(9) Статья очень полезная, вы не расстраивайтесь. Гора комментариев как раз об этом и говорит.
20. Пользователь Инфостарта (infostart user) 15 28.12.16 14:25 Сейчас в теме
21. Сан Саныч (herfis) 117 29.12.16 10:12 Сейчас в теме
(18)
Термин "гарантированная доставка" не должен зависеть от контекста и он не применим точно здесь

Ок. Раз не должен зависеть от контекста, то вы подразумеваете его исчерпывающее определение. Дайте ссылочку, плиз. Я такого не нашел.
Везде зависит от контекста. Например, как по вашему - TCP обеспечивает "гарантированную доставку" или нет?
22. Петр Базелюк (pbazeliuk) 1284 29.12.16 11:49 Сейчас в теме
(21) Он обеспечивает надежную передачу данных, но "негарантированную". Термин "гарантированная доставка" появился как описание паттерна. Действительно, пример, который не связан с очередями, сложно найти.
Оставьте свое сообщение