BuBux,
да, забыл пояснить modulesEl.html(''); здесь мы вызываем метод html, при этом передаём туда пустую строку ''. Таким образом, внутри элемента modulesEl будет пусто. Но так же можно добавить туда любой другой html.
Те вам нужно заменить на
Analka, ну, тогда валидация и исправление введенных данных спасут.
Причем и на фронтэнде сделать понятный интерфейс, с автодобавлением/выбором протокола, и в бекэнде проверять, есть ли https:// в ссылке, и добавлять если нужно.
ff0xff, ну тогда ясно, значит тут наложилось ваше не полное объяснение задачи на мой узко направленный прожеткор мышления.
У вас иная задача, это потоковый вывод, да еще и текста.
ff0xff, (браузер не браузер не суть)
НО.
Из вашего описания я изначально решил что к клиенту обращаетесб вы, а тут выходит, клиент обращается к вашего API и ждать результат?
ff0xff, всё что вы описали, будет и в варианты как вы решили делать.
А дупликаты легко убираются, простейшей логикой проверки, кто что запросил.
Повторюсь, наш вариант делает тоже что и ваш, кроме блокировки браузера и основного потока вывода.
Спрашивается, у вас задачи заблоировать бразуер пользователя на 30 минут? Если нет, то преимуществ вашего варианта просто не существует.
Хотя нет, вру, можно придраться. Он рабоает без всяких доп уведомлений, js и тп.
Но, кстати, и мой вариант можно так реализовать, добавив автообновления страницы с результатом (это даже без js можно сделать).
Так всё же нет, преимуществ вашего подхода я пока что не вижу.
ff0xff, ну подождите 30 минут и риалтайм это уже несовместимые вещи.
Но да ладно. не понимаю почему вы сопротивляетесь.
Я вам говорю, что блокировать браузер подобным запросом плохая идея, и предлагаю просто перенести выполнение обработки в отдельный поток. Эо уберет куча проблем, но никак не изменит логики работы.
Вы всё так же можете отдавтаь и кусочки если нужно, и обновлять БД, и напистаь комопнент который в режиме реального времени будет показываь прогресс либо текущие результаты и тд и тп(и да тут уже активно нужен js).
Но даже без этих фич, вариант с созданием отдельного потока для тяжелой задачи, с последующим уведомлением по завершению(или по этапно) лучше блокировки потока ввода/вывода что вы предлагаете.
Те он не хуже по требуемым качествам и однозначно лучше по куче проблем.
Ну, либо мы как то не понимаю друг друга, поэтому говорим и разных вещах, я допускаю что я чего-то не понял в вашей задаче.
Но посидев и прикинув варианты, всё равно не нахожу защиты для вашего метода.
Дмитрий, и это кстати тоже. Я больше вижу проблемы что пользователю в таком варианте событий легче потерять данныею. Закрыть вкладку, нажатьь обновить и всё.. снов аждать 20 минут.
В любом случае кейс топикастера крайне неудачный. Не очень ясно почему всё же он сопротивляется.
Я сам когда-то попадался на подное(очень похожйи случай был). а потом это превращается в уродский легаси на которыё еще(после таки понимания лажи) нужно искать время на переписывание.
ff0xff, у вас и будет один запрос. Я не вижу проблемы.
Мы меняем только то, как это видит пользователь.
В любом случае вы же контролируете запрос и ответ.
Пользователь отдал вам запрос, вы ему говорите ждать, а параллельно создаете задание с запросом к Power BI, которое может выполнятся сколь угодно долго, но как будет готово вы скажете пользователю. при этом это будет параллельный независимый процес. никак не блокирющий текущий поток работы пользователя.
Владислав Лысков, смотрите, в вашем коде $first_age - массив, результат действия функции array_column.
Внутри вашей функции calculate_age вы используете strtotime - ему нужна строка.
$first_age[0] - это мы взяли первый элемент массива.
Либо второй вариант, я выше писал, мы в цикле проходим по каждому элементу массива отдельно и сразу его передаём.
ff0xff, ну отлично помогает.
Используете Task Scheduling для настройки выставления и выполнения заданий. События для перехвата событий. Уведомления для уведомлений (не важно имейл, пуш, мессенджеры).
Короче говоря в Ларавел можно сделать жту задачу красиво, масштабируемо и прозрачной.
И пусть что тягать нужно каждый раз.
Суть в том, чтобы пользователь не висел с "зависшим" бразуреом, так как там у вас нет контроля и пользователь в любой момент прервёт всё или отправит повторный запрос и тп.
А так, с отложенной тяжелой задачей, вы всё контролируете, меньше дупликатов и тп и тд.
В любом случае это единсвенно верный подход для тяжелых задач. Ведь пользователю та ки так ждать выоплнения. Но в случае нормальной реализации, меньше шансов что что-то пойдет не так.
Покажи побольше твоего composer.json, можешь там удалить части что касается твоего пакета непосредственно, если это тайна.
Или хотя бы покажи строчку с указанием версии php
Comsequent, не покатит же, там другой домен же. Это работает когда у себя такое делаешь. А здесь iframe вставляется с другого домена, инстаграмного. Доступа не будет.
PHPjedi,
Это вопрос уже больше из UX и в тч UI. У многих такие моменты реализованны определенным путём не потому что правильны, а исторически уже так сложилось.
Если описать общую движуху, то выходит примерно так:
Итак, мы не знаем пользователя и он пришёл в первый раз:
Смотрим локаль браузера, смотрим GeoIP.
Сам интерфейс изначально делаем на языке локали браузере (либо на языке по умолчанию, если языка пользователя нет, обычно это английский).
На основе данных из GeoIP мы решаем, показать ли небольшое всплывающее окошко внизу(важно чтобы оно было не блокирующим основной интерфейс и легко и понятно закрывалось), с предложением выбрать нужный язык.
Например, человек зашел, у него в браузере локаль английская, а ip русский, вот ему и показать миниокошко внизу с сообщением, что есть возможность включить русский язык. Если он его закрыл, значит пиши в localStorage язык его браузера (в данном случае английский), если согласился то соответственно ставим язык русский (или тот что мы предложили). Так же в этом окошке хорошо дать ссылку/указание на все языки.
При это важно, пока пользователь ничего не выбрал, мы ничего никуда не записываем, тк управление должно оставаться на уровне пользователя. Он у себя в системе/браузере меняет язык, и после этого меняется язык и в вашем приложении.
Всё что выше описано касается и постоянных и зарегестрированных пользователей. Пока, человек не сделал активных действий по сохранению настроек, мы действуем на основе данных о локали из устройства (используя GeoIP только для того чтобы не сильно намекнуть на возможность выбора языка страны откуда он вышел в сеть).
Таким образом, пользователь сам у себя определяет с каким языком, на каких своих устройствах он работает.
Теперь насчет сохранения у зарегестрированных пользователей. Конечно же хранить в базе данных. Для таких настроек удачно подходит тип поля json в sql (есть во многих современных бд и в mysql, mariadb, postgresql и тп) в котором удобно хранить различиные подобные настройки пользователя, язык, тема оофрмления и тп.
Итак, приоритеты по выбору языка, от высшего к низшему, каждый действует если он установлен, иначе игнорируется:
1. Настройки из БД (конечно актуальны только для зарегистрированных, будут действовать на любом устройстве где он пройдёт аутентификацию )
2. localStorage (на каждом устройстве/браузере своя)
3. Локаль из устройства(браузера)
3.1 Поправка по GeoIP
Если всё сделать правильно, то выйдет прозрачная и простоя система для пользователя, где дурацкие всплывающие окошки показываются обычно один раз (он либо закрыл его и мы сохранили в localstorage язык его локали браузера, либо он вбырал предложенный язык на основе GeoIP), и пользователь получит скорее всего сайт изначально в ожидаемом виде.
да, забыл пояснить
modulesEl.html('');
здесь мы вызываем метод html, при этом передаём туда пустую строку''
. Таким образом, внутри элемента modulesEl будет пусто. Но так же можно добавить туда любой другой html.Те вам нужно заменить на