как приятно читать защитника хранимок, а то тут мне навтыкали кучу минусов в карму только за упоминание о них. и ещё приятнее почитать одного из гуру очень популярного ранее форума.
Во первых как минимум на этот кусок хтмла надо навесить события, /
после озвучивания этой "проблемы", остальное читать не тянет. просто прочитайте про делегирование, и не нужно будет "навешивать события". мультиязычность - не вижу проблем, если видите - это ваши проблемы...
Все что связано с отображением должно строиться на уровне клиента.
в итоге имеем веб вариант 1с - пока загрузится, пока отобразит - в Китае бамбука не хватит, чтоб курить в это время....
И собсна разбираться как потом из хтмла вытянуть данные ради "оптимизации" не хочется
надо будет вытянуть данные для того чтобы их можно было отредачить, чтобы их можно было куда засейвить, и прочее.
это проблемы? ну это уже слишком.... элементарные вещи надо видеть сразу.
ребята! ну это не стоит и выеденного яйца.....
ели есть вопросы как решить эти ваши "проблемы" - пишите в "диалоги". ну или тут ждите сутки :)
С бэка приходит строка , фронт ее преобразует в элементы dom. Бэк стоит строку json, xml или html. Бэку по затратам по-барабану , что строить. Фронту же есть разница с чем работать, с json, xml или html. Для фронта самое оптимальное - html вставка в dom одна команда. Xcc? кто-то пробовал это сделать в современных браузерах? Результат приятно удивит. Да и есть уже инструменты... Теневой дом - та же работа по преобразованию входной строки в строку html . Бэки не умеют строить html? Пусть фронтеры дадут шаблон, чтоб его бэки заполнили. Или нафиг такие бэки. Серверный рендеринг? Хорошая идея загрузить сервер бесполезной работой по преобразованию из одной строки в другую..
почему так сурово? любые события на сервере позволяют отправлять сообщения сразу клиенту, время на транспортировку сообщения в сети минимально, даже из-за того что "кпд" сообщения близко к 100%. передается минимум служебной информации самого протокола. время на обработку - оно будет практически одинаково для любой системы ( если не считать специально заточенных только под одну задачу).
самое лучшее было на sql.ru - не было ни оценок, ни кармы. были предупреждения от модераторов, баны на час, день и прочее вреvя, бан по ip. споры и обсуждения до усрачки. НО истина всегда была. каждый мог высказать своё мнение - хочешь -ответь, не хочешь не отвечай. и, надо сказать, те кто обижался на критику, уходили с форума не достигнув ничего, а те кто воспринимал критику - достигали много. таких было не мало за 20 лет, до известных событий... а по SO - многие модераторы просто не в курсе задаваемых вопросов, закрывают их. и пишут всякую ерунду задающим. како-то учет ответов и участия - не есть плохо, но только в том случае, если это не ограничивает. чью-то свободу действий.
и gpt учится именно на таких сайтах, они исчезнут и gpt поглупеет. одной документации будет не достаточно.
вместо ремня можно использовать металлический тросик, а передачу перемещения по тросикку использовать вариант от перемещения строительных люлек (фасадного подъемника), когда трос проходит через два ролика.
в середине 80-х пришлось ремонтировать импортный станок, когда разобрались что и как оказалось,что его основа однобитный процессор собранный на рассыпухе типа 155 серии...
Независимо от версии Hibernate и типа выполняемого запроса, в ответ вы получите Object[] или List Object[]
вот в этом и заключатся тормознутость хибера, сначала он заполняет лист, а потом из этого листа извлекается что нужно и куда нужно. а ведь можно сразу из резульсета заполнить нужное.к примеру в web из результсета строить таблицу, для десктопа ещё терпимо такое , но для web каждая мс дорога, да и зачем загорождать память временным объектом?
Предположим, при вводе текста в инпут мы хотим отправлять запрос на сервер, чтобы получить выпадающий список вариантов под введенное значение.
для данного применения достаточно просто ограничить первую отправку на сервер 3-4 символами. и реализовать разделение на группы пробелом, тогда на сервере логика выбора будет поле like %1группа% and поле like %2группа% и так далее. как правило редко приходится вбивать более 3-х групп для выборки аз 10 лямов записей - из практики применения. замыкания, конечно хорошо надо знать, но и применять надо по месту.
корпоративных порталов не так много, хотя кто их считал , с их закрытым доступом... но применение бота не заканчивается только на входе в портал, этот же бот может открывать и вход по RDP для конкретного ip данного юзера. и ещё - использование логина/пароля и/или телефона вызывает ввод этих логинов/паролей/телефонов/мыл, что не всегда есть хорошо. при использовании бота ничего такого вводить на странице браузера не нужно, просто увидеть 3-значное число и ввести его в боте. всё в открытую. и не надо никому писать -"ни кому не сообщайте это число".
ну не нравится такой вариант - не используй. Есть такое, работающее - почему бы не поделиться?
есть вариант когда регистрация происходит в ручном режиме - оператор (администратор портала) вводит телефон и права/роли для юзера (такое для корпоративного применения). юзер при входе на портал видит код. вводит этот код в телеге и на странице и вместо кода открывается его станица (ы). регистрация в телеграмм боте произойдет если юзера внесли в базу портала. удобство - не надо ничего помнить.
Если RDP не используется, то выключите его и отключите на брандмауэре сети внешние соединения с локальными машинами на порту 3389 (TCP/UDP) или любом другом порту RDP. самое действенное решение. а ещё лучше не просто отключать, а фильтровать, точнее открывать порт RDP только для данного клиента прописывая адрес в роутере или каком другом входном устройстве. организовывается просто с помощью небольшого сайтика и телеграмбота. это не совсем двухфакторная авторизация. но работает стабильно.
- не нравятся кошки?
- Да Вы просто не умеете их готовить!
не плохо, но не хватает про сортировку в агрегатирующих функциях и её влияние на общую сортировку результата
как приятно читать защитника хранимок, а то тут мне навтыкали кучу минусов в карму только за упоминание о них. и ещё приятнее почитать одного из гуру очень популярного ранее форума.
после озвучивания этой "проблемы", остальное читать не тянет. просто прочитайте про делегирование, и не нужно будет "навешивать события".
мультиязычность - не вижу проблем, если видите - это ваши проблемы...
в итоге имеем веб вариант 1с - пока загрузится, пока отобразит - в Китае бамбука не хватит, чтоб курить в это время....
это проблемы? ну это уже слишком.... элементарные вещи надо видеть сразу.
ребята! ну это не стоит и выеденного яйца.....
ели есть вопросы как решить эти ваши "проблемы" - пишите в "диалоги". ну или тут ждите сутки :)
С бэка приходит строка , фронт ее преобразует в элементы dom. Бэк стоит строку json, xml или html. Бэку по затратам по-барабану , что строить. Фронту же есть разница с чем работать, с json, xml или html. Для фронта самое оптимальное - html вставка в dom одна команда. Xcc? кто-то пробовал это сделать в современных браузерах? Результат приятно удивит. Да и есть уже инструменты... Теневой дом - та же работа по преобразованию входной строки в строку html . Бэки не умеют строить html? Пусть фронтеры дадут шаблон, чтоб его бэки заполнили. Или нафиг такие бэки. Серверный рендеринг? Хорошая идея загрузить сервер бесполезной работой по преобразованию из одной строки в другую..
откуда вывод, что websocket для не больших сообщений? практика говорит, что и большие бинарные файлы можно передавать. а текстовые тем более
странная таблица сравнения. чем отличается передача xml по soap от передачи того же xml по wedsocket? и чем лучше rest для веб-сервисов от websocket?
и чем меньше нагрузка на сеть GraphQL по сравнению с websocket?
вот интересно - тут написано,<двусторонний, позволяет обмениваться данными в реальном времени, > а в комментариях к https://habr.com/ru/companies/otus/articles/770256/ сомневаются в реал тайм ws :)
почему так сурово? любые события на сервере позволяют отправлять сообщения сразу клиенту, время на транспортировку сообщения в сети минимально, даже из-за того что "кпд" сообщения близко к 100%. передается минимум служебной информации самого протокола. время на обработку - оно будет практически одинаково для любой системы ( если не считать специально заточенных только под одну задачу).
не нравится websocket ? ты просто не умеешь его готовить..
самое лучшее было на sql.ru - не было ни оценок, ни кармы. были предупреждения от модераторов, баны на час, день и прочее вреvя, бан по ip. споры и обсуждения до усрачки. НО истина всегда была. каждый мог высказать своё мнение - хочешь -ответь, не хочешь не отвечай. и, надо сказать, те кто обижался на критику, уходили с форума не достигнув ничего, а те кто воспринимал критику - достигали много. таких было не мало за 20 лет, до известных событий...
а по SO - многие модераторы просто не в курсе задаваемых вопросов, закрывают их. и пишут всякую ерунду задающим. како-то учет ответов и участия - не есть плохо, но только в том случае, если это не ограничивает. чью-то свободу действий.
и gpt учится именно на таких сайтах, они исчезнут и gpt поглупеет. одной документации будет не достаточно.
опередил :)
вместо ремня можно использовать металлический тросик, а передачу перемещения по тросикку использовать вариант от перемещения строительных люлек (фасадного подъемника), когда трос проходит через два ролика.
мтс не позорьтесь,, что за картинка с java?
после такого стоит ли доверять всему остальному?
в середине 80-х пришлось ремонтировать импортный станок, когда разобрались что и как оказалось,что его основа однобитный процессор собранный на рассыпухе типа 155 серии...
вот в этом и заключатся тормознутость хибера, сначала он заполняет лист, а потом из этого листа извлекается что нужно и куда нужно. а ведь можно сразу из резульсета заполнить нужное.к примеру в web из результсета строить таблицу, для десктопа ещё терпимо такое , но для web каждая мс дорога, да и зачем загорождать память временным объектом?
для данного применения достаточно просто ограничить первую отправку на сервер 3-4 символами. и реализовать разделение на группы пробелом, тогда на сервере логика выбора будет поле like %1группа% and поле like %2группа% и так далее. как правило редко приходится вбивать более 3-х групп для выборки аз 10 лямов записей - из практики применения. замыкания, конечно хорошо надо знать, но и применять надо по месту.
какого уровня разработчик, если про бп он пишет такое? бп это основа отладки как и выводы в консоль. а автор еще не сказал про пошаговую отладку,
куда скатился хабр....
пишет для джуниоров...это уже должен знать первоклашка. а по правильному это называется пошаговая отладка.
а ещё там есть зайти в блок (процедуру, функцию,метод), выполнить до следующей точки останова...
корпоративных порталов не так много, хотя кто их считал , с их закрытым доступом... но применение бота не заканчивается только на входе в портал, этот же бот может открывать и вход по RDP для конкретного ip данного юзера. и ещё - использование логина/пароля и/или телефона вызывает ввод этих логинов/паролей/телефонов/мыл, что не всегда есть хорошо. при использовании бота ничего такого вводить на странице браузера не нужно, просто увидеть 3-значное число и ввести его в боте. всё в открытую. и не надо никому писать -"ни кому не сообщайте это число".
ну не нравится такой вариант - не используй. Есть такое, работающее - почему бы не поделиться?
есть вариант когда регистрация происходит в ручном режиме - оператор (администратор портала) вводит телефон и права/роли для юзера (такое для корпоративного применения). юзер при входе на портал видит код. вводит этот код в телеге и на странице и вместо кода открывается его станица (ы). регистрация в телеграмм боте произойдет если юзера внесли в базу портала. удобство - не надо ничего помнить.
Не поддерживается...... Не надо пустых слов, надо факты https://caniuse.com/?search=websocket
Более высокая нагрузка на сервер.... Ну это уже ваще лажа
Требуется доп. настройка .... Охрененный минус ,
Прошло более 11 лет с момента появления ws, а тут это рассматривается как суперновость
Уже давно есть либы даже для ардуинок.
Прежде чем писать, нада воспользоваться поиском по данной теме, и не публиковать школьные доклады
Если RDP не используется, то выключите его и отключите на брандмауэре сети внешние соединения с локальными машинами на порту 3389 (TCP/UDP) или любом другом порту RDP.
самое действенное решение. а ещё лучше не просто отключать, а фильтровать, точнее открывать порт RDP только для данного клиента прописывая адрес в роутере или каком другом входном устройстве. организовывается просто с помощью небольшого сайтика и телеграмбота. это не совсем двухфакторная авторизация. но работает стабильно.