Алексей, Все верно, мне нужно это для промежуточного сохранения результата. Но один пользователь может заполнить несколько форм с разными параметрами (пример врач заполняет форму с данными о пациенте). Надим Закиров, правильно указал на то, что в таком случае придется следить и за порядком параметров в строке...
Все же самый верный вариант будет брать из строки поиска важные параметры и использовать их в качестве ключа отсортировав по алфавиту
Alexander3928, если цель будет проверять токен на сервере то придется каждую итерацию setInterval запрашивать статус у сервера. Значит способ неправильный
Vitsliputsli, Не понятно в какую часть (метод) Ratchet вставить код, который будет периодически выполняться. Имея доступ к тому же ConnectionInterface, в котором работает чат
Спасибо за Ваш развернутый ответ. Понятнее, конечно, не очень стало ), но все равно спасибо. Я обязательно позже отмечу ваш ответ как решение, но думаю кто–то еще выскажется.
Хуже в понимании становится с вебпаком, когда он каким-то образом начинает работать с HTML файлами. А ведь с ними еще должны работать и php и какой-то js код
У меня проблема немного другого характера. На js я могу сделать практически все что требуется для вывода информации, взаимодействия Dom между собой, получение, отправка на сервер. Ну т.е. чтобы создать свой некий интерактивный сервис, где основа может быть даже js, я могу, но я это все могу только с нуля сам написать, на нативном js или jQuery, но не понимаю как работать с кучей всего того, что я перечислял вверху.
Pavel K, Ситуация такая: пользователь листает страницу на которой открыты посты с 0 по 9, вторая страница, это соответственно с 10 по 19. Представьте выборку для первой страницы:
SELECT p.`id`, p.`title`
FROM `posts` p
LEFT JOIN `visibled` v ON v.`id` = post.`id`
WHERE v.id IS NULL
LIMIT 0, 10
Пользователь просмотрел посты 5,6,7,8,9
значит при следующей выборке (странице), вот в эту часть они уже не попадут:
SELECT p.`id`, p.`title`
FROM `posts` p
LEFT JOIN `visibled` v ON v.`id` = post.`id`
WHERE v.id IS NULL
И их место займут посты с 10 по 14
А соответственно, если я сделаю второй раз LIMIT 0, 10, то посты по домерами 10-14 окажутся в этом списке. Т.к. я запросил 10 первых постов которые соотвествуют условию. Так вот представьте что я беру вторую страницу с LIMIT 10, 10 а значит пользователь не увидит посты с ID 10-14 потому что они оказались уже за пределами этой выборки, т.к. они в этом запросе виртуально попадают в первую страницу на место в списке 5-9.
Да, я действительно не учел вариант с массивом, но в случае, когда, мы проверяем данные, которые не должен изменять пользователь, выводить ошибки не корректно. Ведь по ошибкам можно найти уязвимости и определить библиотеку, в которой так же могут быть уязвимости
