Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Как обновлять "долгоиграющие" веб-приложения?
|
|||
|---|---|---|---|
|
#18+
Есть веб-приложение, которое у пользователя может быть открыто в бразере очень долго (до нескольких дней). При этом, клиентская часть активно взаимодействует с серверной (подгрузка/обновление контента на странице, выполнение различных действие и т.п.) Клиентская и серверная часть оформлены как 1 проект, деплоятся на прод синхронно. Иногда возникают ситуации, когда у пользователя в браузере открыта старая версия страницы, а на сервер задеплоена уже новая версия приложения. При этом, логика новой версии иногда не совместима cо старой клиентской частью (меняются css, dom в подгружаемом контенте => при обновлении контент отображается некорректно , меняется логика в rest-вызовах => ajax валится). Как лучше разруливать такие ситуации? Пока единственный вариант, который кажется приемлимым - хранить на сервере номер версии, протаскивать её в ajax-запросах на клиент, и выдавать ошибку, если версия не совпадает с версией на клиенте. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2014, 09:50 |
|
||
|
Как обновлять "долгоиграющие" веб-приложения?
|
|||
|---|---|---|---|
|
#18+
Клавишей F5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2014, 11:01 |
|
||
|
Как обновлять "долгоиграющие" веб-приложения?
|
|||
|---|---|---|---|
|
#18+
Время от времени с клиента по ajax запрашивать версию и если изменилась, то location.href = location.href; ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2014, 11:09 |
|
||
|
Как обновлять "долгоиграющие" веб-приложения?
|
|||
|---|---|---|---|
|
#18+
Малыхин Сергей, Ctrl+F5 Автору. В css и прочую статику добавляют номер версии во избежание кеширования. my_css.css?087 - так было 5 лет внезапно вы обновили my_css.css. стало my_css.css?088 браузер кеширует по урлу, урл поменялся - в кеше обновится с сервера по js, jpg и тп - аналогично поступают. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2014, 13:37 |
|
||
|
Как обновлять "долгоиграющие" веб-приложения?
|
|||
|---|---|---|---|
|
#18+
Малыхин СергейКлавишей F5 спасибо, кэп. осталось донести эту мысль до всех пользователей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2014, 15:11 |
|
||
|
Как обновлять "долгоиграющие" веб-приложения?
|
|||
|---|---|---|---|
|
#18+
st_stВремя от времени с клиента по ajax запрашивать версию и если изменилась, то location.href = location.href; - дополнительная нагрузка на сервер, не особо хотелось бы. - всё равно остается вероятность, что между двумя проверками кто-то попадет на обновление. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2014, 15:19 |
|
||
|
Как обновлять "долгоиграющие" веб-приложения?
|
|||
|---|---|---|---|
|
#18+
debloggerМалыхин Сергей, В css и прочую статику добавляют номер версии во избежание кеширования. my_css.css?087 - так было 5 лет внезапно вы обновили my_css.css. стало my_css.css?088 браузер кеширует по урлу, урл поменялся - в кеше обновится с сервера по js, jpg и тп - аналогично поступают. кейс: - у пользователя загружена страница, и перезагружать её он не собирается. - на сервере обновлись js и css. - пользователь, не перезагружая страницы, выполняет аякс-запрос, подгружающий порцию данных. в подгружаемом html есть стили, описанные в css-файле (который на сервере уже изменился). новые js и css не применятся, так как страница уже загружена. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2014, 15:28 |
|
||
|
Как обновлять "долгоиграющие" веб-приложения?
|
|||
|---|---|---|---|
|
#18+
madbear- всё равно остается вероятность, что между двумя проверками кто-то попадет на обновление.Тады на какое-то время придется оставлять на сервере старые версии, соответствующие версии клиента. Ни и имена файлов делать вида style.ver0987.css. Пока загружена старая версия страницы - будет свои старые файлы требовать, а новая уже свои. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2014, 15:28 |
|
||
|
Как обновлять "долгоиграющие" веб-приложения?
|
|||
|---|---|---|---|
|
#18+
madbear, Стирайте сессию после обновления. В одноточечной архитектуре элементарно организовать проверку по времени. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2014, 15:48 |
|
||
|
Как обновлять "долгоиграющие" веб-приложения?
|
|||
|---|---|---|---|
|
#18+
deblogger, Браво! Всех на авторизацию! По каждому коммиту ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2014, 15:52 |
|
||
|
Как обновлять "долгоиграющие" веб-приложения?
|
|||
|---|---|---|---|
|
#18+
vklemadbear- всё равно остается вероятность, что между двумя проверками кто-то попадет на обновление.Тады на какое-то время придется оставлять на сервере старые версии, соответствующие версии клиента. Ни и имена файлов делать вида style.ver0987.css. Пока загружена старая версия страницы - будет свои старые файлы требовать, а новая уже свои. Старые версии чего именно? 1. Проекта целиком? если да, не очень понятно, как веб-сервер будет понимать, какую версию проекта для какого запроса отдавать. 2. только стилей? если да, непонятно, как быть, если меняется динамический контент. к примеру, в старой версии: style.ver1:css: .name {color: red}; endpoint-for-ajax.php: echo "<div class='name'>$first_name $last_name</div>"; в новой версии: style.ver2:css: .nick {color: red}; endpoint-for-ajax.php: echo "<div class='nick'>$nick</div>"; клиент с версией ver1 запрашивает аяксом новый контент, получает html, для которого в style.ver1.css стили не прописаны => отображается гуано) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2014, 15:59 |
|
||
|
Как обновлять "долгоиграющие" веб-приложения?
|
|||
|---|---|---|---|
|
#18+
vkledeblogger, Браво! Всех на авторизацию! По каждому коммиту И давно вы тут авторизовались вручную? Назовите точную дату. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2014, 16:06 |
|
||
|
Как обновлять "долгоиграющие" веб-приложения?
|
|||
|---|---|---|---|
|
#18+
Тогда циклические проверки версий не нужны. Можно в каждом плановом ajax-запросе с клиента посылать какой-нить request header по типу "version: 1.0.0" (да можно версию в любое место сунуть, хоть в куки, хоть в get-параметр). Если версия с сервером не совпала, то обратно прилетает json с флагом, что нужно обновиться, далее на клиенте location.href. Всем css/js отрубить кэш через cache-control. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2014, 16:13 |
|
||
|
Как обновлять "долгоиграющие" веб-приложения?
|
|||
|---|---|---|---|
|
#18+
madbear, Делайте ajax запросы каждые 10 минут например. А на сервере пускай коммиты не сразу тянутся на продакшн, а точно также каждые 10 минут. Тогда Вы получите полную синхронизацию (то есть только прошло обновление и через несколько секунд клиент их стянул). Вот и всё :) Нагрузка минимальная, а синхронизация полная. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2014, 16:16 |
|
||
|
Как обновлять "долгоиграющие" веб-приложения?
|
|||
|---|---|---|---|
|
#18+
авторИногда возникают ситуации, когда у пользователя в браузере открыта старая версия страницы, а на сервер задеплоена уже новая версия приложения. При этом, логика новой версии иногда не совместима cо старой клиентской частью (меняются css, dom в подгружаемом контенте => при обновлении контент отображается некорректно , меняется логика в rest-вызовах => ajax валится). - Для этого нужно обновить клиентское приложение до того как начнут обрабатываться(отображаться) полученные данные. - Для того что бы клиентское приложение обновилось оно должно получить информацию о том что серверная часть изменилась и что серверная часть приложения не совместима с текущей клиентской частью. По сути это вопрос архитектуры все описание которой заканчивается словами "Есть веб-приложение" имхо: deblogger предложил правильное решение хранить версию приложения куках (печенек может быть несколько) на сервере при получении запроса проверять версию приложения и в случаи отличия заставить клиент обновить приложение и заново отправить запрос если это возможно ( например использовать код http 303 ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2014, 16:18 |
|
||
|
Как обновлять "долгоиграющие" веб-приложения?
|
|||
|---|---|---|---|
|
#18+
madbearклиент с версией ver1 запрашивает аяксом новый контент, получает html, для которого в style.ver1.css стили не прописаны => отображается гуано)Не-не, мешать новое со старым не надо. Клиент должен запрашивать и получать контент своей версии на всех запросах. Для файлов оно вроде бы просто. Для асинхронных запросов в принципе тоже самое - обращаться по своему URL. Как вариант, если не хотите или нет возможности менять от версии к версии URL для асинхронных запросов, тогда номер версии можно хранить в куке, например - ее можно установить при отдаче основной страницы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2014, 16:19 |
|
||
|
Как обновлять "долгоиграющие" веб-приложения?
|
|||
|---|---|---|---|
|
#18+
madbear, Это же не техническая задача. Техника может быть какой угодно. Советовать ничего нельзя не зная устройства вашей техники. Логика простая. Допустим В сессии есть дата взятая из конфига, с бд например, таймштамп. Если все запросы идут через index.php (как обычно сейчас принято делать), то ваш аякс там же пройдет. И упрется в элементарную проверку данных из конфига с данными в кеше (сессии). Если совпадает - ок. Не совпадает - сессию выкашиваете, аякс напишет 301 Moved Permanently - скрипт на клиенте поймет что к чему и делает релод и по кукам все загрузится на то же самое место, если на странице есть хеши (букмарки по-старому). Теоретически по 301 должен вылезти какой-то диалог если снабдить заголовок еще и урлом. Я пока такого не видел. В крайнем случае просто придумайте свой код по которому сервер может сообщить клиенту что надо бы страницу того. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2014, 16:20 |
|
||
|
Как обновлять "долгоиграющие" веб-приложения?
|
|||
|---|---|---|---|
|
#18+
debloggervkledeblogger, Браво! Всех на авторизацию! По каждому коммиту И давно вы тут авторизовались вручную? Назовите точную дату.22 февраля 2014 года. А что? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2014, 16:20 |
|
||
|
Как обновлять "долгоиграющие" веб-приложения?
|
|||
|---|---|---|---|
|
#18+
vkle, Значит второе из двух. Теперь можете включить куки. Хватит уже страдать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2014, 16:21 |
|
||
|
Как обновлять "долгоиграющие" веб-приложения?
|
|||
|---|---|---|---|
|
#18+
madbearЕсть веб-приложение, которое у пользователя может быть открыто в бразере очень долго (до нескольких дней). При этом, клиентская часть активно взаимодействует с серверной (подгрузка/обновление контента на странице, выполнение различных действие и т.п.) Клиентская и серверная часть оформлены как 1 проект, деплоятся на прод синхронно. Иногда возникают ситуации, когда у пользователя в браузере открыта старая версия страницы, а на сервер задеплоена уже новая версия приложения. При этом, логика новой версии иногда не совместима cо старой клиентской частью (меняются css, dom в подгружаемом контенте => при обновлении контент отображается некорректно , меняется логика в rest-вызовах => ajax валится). Как лучше разруливать такие ситуации? Пока единственный вариант, который кажется приемлимым - хранить на сервере номер версии, протаскивать её в ajax-запросах на клиент, и выдавать ошибку, если версия не совпадает с версией на клиенте.нормальный вариант у вас, только я-бы ещё и при запросе с клиента передавал его версию, а так же флаг состояния, что есть несохранённые данные с клиента. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2014, 16:51 |
|
||
|
Как обновлять "долгоиграющие" веб-приложения?
|
|||
|---|---|---|---|
|
#18+
debloggervkle, Значит второе из двух. Теперь можете включить куки. Хватит уже страдать.Большое спасибо за ценные указания. Разрешите выполнять бегом? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2014, 19:43 |
|
||
|
Как обновлять "долгоиграющие" веб-приложения?
|
|||
|---|---|---|---|
|
#18+
madbear Есть веб-приложение, которое у пользователя может быть открыто в бразере очень долго (до нескольких дней) . При этом, клиентская часть активно взаимодействует с серверной (подгрузка/обновление контента на странице, выполнение различных действие и т.п.) Клиентская и серверная часть оформлены как 1 проект, деплоятся на прод синхронно. Иногда возникают ситуации, когда у пользователя в браузере открыта старая версия страницы, а на сервер задеплоена уже новая версия приложения. При этом, логика новой версии иногда не совместима cо старой клиентской частью (меняются css, dom в подгружаемом контенте => при обновлении контент отображается некорректно , меняется логика в rest-вызовах => ajax валится). Как лучше разруливать такие ситуации? Пока единственный вариант, который кажется приемлимым - хранить на сервере номер версии, протаскивать её в ajax-запросах на клиент, и выдавать ошибку, если версия не совпадает с версией на клиенте. Можно название приложения, которое так долго висит? Или урл... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2014, 21:54 |
|
||
|
Как обновлять "долгоиграющие" веб-приложения?
|
|||
|---|---|---|---|
|
#18+
asws, помню ты js-либу писал, в ней есть аналог jquery-вского live/die + поддержка onchange/submit? Замутная штука как оказалось. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.02.2014, 05:35 |
|
||
|
Как обновлять "долгоиграющие" веб-приложения?
|
|||
|---|---|---|---|
|
#18+
st_stasws, помню ты js-либу писал, в ней есть аналог jquery-вского live/die + поддержка onchange/submit? Замутная штука как оказалось. Ещё какая замутная, как и много других вещей, потому что пока более-менее шаблонный подход, как правило, всё ОК, как чуть нестандартного, так имхо можно многие существующие фреймворки выкидывать, ибо геморроя становится больше , чем пользы :) отвечаю, но это оффтоп в теме, сорри Трудно ответить, потому что трудно сравнивать совершенно разные библиотеки с разными подходами к проектированию... Пишу и сейчас практически любые модули/библиотеки на чистом JS, если нет желания танцевать с бубном вокруг фреймворков. Конечно можно ещё и разные jQuery подключать или ещё что, но необязательно, весь базовый функционал как правило уже есть. ----------------------------- Ответ (попытка ответа) - Насчёт навешивания и снятия обработчиков, у меня конечно есть, но реализация таких вещей, как live/die , думаю, ненужно, потому что подразумевает недостаток гибкости в будущем и различные неожиданные проблемы. Думаю, что у меня аналог .bind(), и можно передавать массив ссылок на объекты или их текстовых ID - для навешивания сразу на все. - Что касается onchange/submit , здесь возможны очень гибкие варианты, например, моя POST-функция составляет строку POST-запроса самостоятельно, и возможны практически любые варианты, включая выбор и предпросмотр множества изображений, а потом их разовую отправку на сервер - одним запросом, потому что стандартный submit по-сути не используется вообще. Давно убедился, что для работы с DOM нет ничего лучше, чем обычный HTML-текст через .innerHTML, который только нужно сформировать как текстовую строку (а операции со строками оптимизированы начиная с ИЕ8), это наиболее кроссбраузерно и имеет максимальную скорость выполнения. Многие функции моих библиотек формируют нужную HTML-строку, довольно гибко получается, работает быстро и без глюков. ----------------------------- Пример: у меня есть аналог стандартного alert(), но туда передаётся html-код, и разумеется сразу появится и станет доступным модальное окно, ничего не мешает донавесить нужные обработчики на временно созданные, согласно переданному HTML-коду, элементы. Аналогично слои, окна, JS-Grid, и т.д., куда можно передавать HTML-части кода, которые будут встроены. Гибко и просто. ----------------------------- Дополнение У меня собственные аналоги многих плагинов и расширений (анимация, оконная система, меню, JS-Grid, drag & drop, слои, Canvas, форматированный ввод (число, телефон, календарь, Spinner-счётчик, Checkbox), работа с изображениями (всплывание, ротация и т.д.), много переменных с информацией о среде, работа с локальным хранилищем (запись-чтение 1 и 2-х мерных массивов), работа с классами и объектами, много функций общего назначения и т.д., сам не помню всего уже, что накопил за несколько лет). Весь нужный для проекта функционал находится в одном JS-файле со множеством внутренних системных функций, чтобы исключить дублирование кода, пока ни разу размер самой большой библиотеки не был более 60Кб (без сжатия, без коментов). И ещё я непонимаю, зачем в JS нужно встраивать ООП, но о вкусах не спорят... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.02.2014, 23:47 |
|
||
|
Как обновлять "долгоиграющие" веб-приложения?
|
|||
|---|---|---|---|
|
#18+
Я пока для теста простенький live навесил - цепляюсь к document и через matchesSelector() и event.target проверяю на совпадение. А как тогда биндишь вновь вставленные в DOM элементы, каждый раз после вставки вызываешь bind()? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.02.2014, 03:13 |
|
||
|
|

start [/forum/topic.php?fid=23&msg=38569514&tid=1463011]: |
0ms |
get settings: |
10ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
43ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
61ms |
get tp. blocked users: |
1ms |
| others: | 252ms |
| total: | 398ms |

| 0 / 0 |
