Очень даже актуален. Я не слежу за фронтендом и то вижу материалы по этой теме.
Например, о яндекс.почте: http://habrahabr.ru/company/yandex/blog/195198/
Спасибо. Читал. (Добавление)
nerv пишет:
еще ссылка
http://learn[dot]javascript[dot]ru/memory-leaks
Это тоже читал. Но это старое. Вопрос насколько актуально. (Добавление)
Попробую вопрос конкретизировать.
то ноды зависнут и не удалятся. Верно, ведь рассуждаю? А другие подводные камни есть в примере? (Добавление)
nerv пишет:
В большинстве случаев этого будет достаточно, иногда избыточно) Чтобы работало, надо правильно писать код
Слушай, а поясни смысл этой конструкции. Т.е. я так понимаю, что ты расширяешь стандартный тип Object, добавляя туда функцию destroy, которая собирает все ключи объекта и удаляет их содержимое (ну и сами ключи тоже). И, насколько я понимаю, эту функцию надо вызывать вручную?
Просто ключи все равно собираются только с первого уровня, а если внутри этого объекта есть еще объекты, то с ними что будет? Тоже вручную? Или расчет на то, что они убьются при очистке первого уровня? В таком случае простым delete(нужный объект) это не решается?
Подскажите, плз, светлые головы! Насколько актуален в 2014 году вопрос утечек памяти в JS? Стал изучать проблему. Пока достаточно поверхностно, но вообще уже складывается ощущение, что код на js - это обильно засаженное минное поле. Чихнул - и потекло
С другой стороны практически все статьи об утечках памяти датируются где-то не позднее 2008 года. Вот я и задумался, а насколько актуальна тема? И если актуальна, то не поделится ли уважаемое сообсчество свежими ссылками где почитать о современном состоянии проблемы?
Заранее благодарен, и прочая, и прочая
Так вот js и css этих блоков привязан к классам, то есть для дива с классом prefix-tab используется css файл с названием prefix-tab.css, и js файл с названием prefix-tab.js
При первой загрузке страницы сайта никакие стили и js не грузится, только html и скрипт, который ищет все используемые блоки на странице, например, блок prefix-tab. Найдя все блоки, которые используются на странице скриптом
я подгружаю js и css файлы данных блоков и вставляю на страницу.
Надеюсь, что идея понятна. Прошу оценить на сколько игра стоит свеч, ведь если на парсинг будет уходить много времени, то прощу сразу подгружать все js и css файлы.
И да, я в курсе, что существует кэш в браузере и браузер загрузив файл один раз, хранит его в кэше. Но задача следующая: сайт планируется быть без перезагрузки страницы, то есть весь html передается ajax-ом. Плюс не должно
быть задержки из-за загрузки ресурсов при первой загрузке страницы.
Логика. Если это шаблонизатор и пользователь где-то сам должен создать стили, а потом еще и раскидать их по файлам с префиксами, то тогда он должнн уметь и css подключить к файлу. Ну, или если там все автоматизировано, то тем более подключить css автоматом. А если ты будешь получать html с подключенным css, то проще выдрать из него линки (тут не уверен, что их вообще надо выдирать и что они не запустятся сами)... Будет сильно быстрее. Только один нюанс надо будет решить, как не дать js работать с размерами элементов загруженного html, пока не подгрузились новые стили.
Ну, и еще момент... Раз уж ты получаешь целиком html, то зачем ждать его загрузки в dom и потом разбирать? Проще до загрузки запустить регулярку на весь html, которая выдерет там все нужные префиксы. Потом подключить соответствующие таблицы стилей, а уж потом интегрировать html в dom. (Добавление)
<sarcasm>Прям удивлён, как же чистый js сработал как надо... и при этом код занял меньше 1000 строк...</sarcasm>
Зачем вообще юзать jq для таких простых операций? Сэкономил 3 минуты и 2 строки кода - потратил 2 дня на решение проблемы.
Поддерживаю сарказм. Я, правда, вообще не понимаю зачем юзать jq... Для селекторов уже есть querySelector...
Но, с другой стороны, как в том анекдоте, когда американцы думали, почему отказал левый двигатель, а русские, а почему не отказал правый Я не могу понять, что в jq, в итоге не работало, потому что у меня прекрасно выполнилось и в jq и на нативном js...
это как onload, врядли из за этого. По идее этот кусок должен отработать после загрузки документа
вообще если честно смущает $('<script>') такая запись...
jquery-1.9.1.js прожевало и не подавилось. Все отрабатывает. Я даже удивился, потому что раньше, насколько помню, если скрипт попадает не в head, то он не запускается. Еще года полтора назад такая проблема была.
Честно пытался понять, что не так. У меня все работает. Не уверен, что делает $(function(){}), если не отслеживает конец загрузки документа, то как вариант, возможно, нода #scrollable не успевает отработаться да попытки вставить в нее скрипт. А так... Проверял в 5 браузерах (FF, Safari, Chrome, Opera, IE11)... Везде пашет...
Грузится столько же. Пробовал ставить в начале принимавшего скрипта return true, и вообще ничего не изменилось, как грузились долго так и осталось.
Узких мест может быть три.
1. Кодировка
2. Передача
3. Декодирование
3. Декодирование отпало.
1. Точно не в процессе кодировки тормозит? Если кодируется через js, то два сообщения в консоль до и после строки с кодированием помогут определить визуально, а можно и время засечь (разность посчитать). В php-то махом кодирует...
2. Тут можно сравнить размер исходного файла и того, что получается на сервере до декодирования. Закодированный через base64 файл точно должен быть больше процентов на 20-25%. Но, вдруг, получается критично больше.
Ну и если с кодированием (п.1) все нормально, размеры файлов отличаются не критично, то, как вариант, стоит копать особенности httprequest.
Я после mysqli_real_escape_string делал подготовленный запрос mysqli_prepare
Он и ломал мою строку, если делать с mysqli_real_escape_string и обычным mysqli_query то все в порядке.
НО, нигде, ни в каких мануалах нет упоминания о несовместимости этих функций...
MAXUS пишет:
Но суть в том, что в базе скорее всего два слэша. Может, два раза ескейпируется при записи где-нибудь еще?
Получается, что первое предположение было верным. Функции не несовместимы, просто в этом случае дублируют друг друга. Первым заходом экранирует \r\n, вторым - слэши. Т.е. все-таки два слэша. Потому в базу записывается chr(92).chr(114).chr(92).chr(110), а не chr(13).chr(10)... Соответственно, и выводится.
Хотя, с pre я немного не в том направлении рассуждал. Конечно, если написать
то на выходе получишь Строка 1\r\nСтрока 2, но суть была не в этом.
Просто php, встретив в строке \r\n, преобразует их в chr(13).chr(10), поэтому
из "Строка 1\r\nСтрока 2" на выходе получается Строка 1.chr(13).chr(10).Строка 2,
а ты из базы получал Строка 1.chr(92).chr(114).chr(92).chr(110).Строка 2...
Оно уже никуда не преобразовывалось, а так и выводилось.
Ниже видно, что получается, если строки до эскейпирования и после (как ты делал в примере) перевести в код.
И, кстати, еще момент. nl2br() не заменяет последовательность chr(13).chr(10) на тэг <br />, а вставляет этот тэг перед. Получается "<br />".chr(13).chr(10). Вот так это становится очевидно:
тег такой есть http://htmlbook[dot]ru/html/frame
позволяет выводить на сайте страницу с другого сайта или ее часть
то есть вывести в письме страницу с вашего сайта - форму
А почему не iframe?! (Добавление)
IllusionMH пишет:
gefard, это ведь так безопасно - давать своим пользователям открывать письма в которых фрэймы. Закосят как и с формами.
Ну как не навешивает? Перехватывает все события onclick, например, на кнопках и ссылках. Вешает, соответственно, свои обработчики событий. Я вот недавно столкнулся. Чето в именах где-то с метрикой пересекся. (Добавление)
DelphinPRO пишет:
а вы не включайте в настройках абсолютно все. Там, ксати около каждой галочки есть примечание, если опция увеличивает нагрузку.
А не я метрику настраивал. Не я, как говорится, прикручивал, не мне и откручивать Даже не вникал, что там настроено.
Ты возьми и запиши в базу просто как есть, без эскейпирования.
Привет, инъекция
Не, ну инъекция, конечно, привет Но зато человек увидит, что на самом деле происходит.
Потому я, в том числе, и предлагаю перенос строк сразу превращать в <br />. Ну, или как вариант, при выводе делать обратную обработку...
Этот костыль конечно можно использовать, но хочется как-то по человечески, тем более я так понимаю такой проблемы НЕ должно возникать в принципе.
А если другой хост, а там все нормально, кароче не вариант...
Хочется разобраться в чем проблема и как ее решить
Ну, во-первых, это не костыль. Это не предложение в качестве решения твоей проблемы, а просто рациональное рассуждение. Если ты в дальнейшем собираешься выводить информацию в браузер (а не в алерты или в консоль через js), то смысла хранить в базе \r\n нет никакого, т.к. при выводе браузер их проигнорирует, а переноса строки не будет, т.к. он делается тэгом <br />... Если, конечно, ты не планируешь выводить все, оборачивая в <pre></pre>...
wget пишет:
В общем тупик мысли...
А во-вторых, я, собственно, не тупанул, а все правильно тебе сказал. Ты попробуй не долбиться апстену, а воспарить над проблемой
Смотри, у тебя есть строка:
Строка 1\r\nСтрока 2
Ты ее выводишь в браузер через <pre> и получаешь:
Строка 1
Строка 2
Все верно. В тэге <pre> браузер воспринимает \r\n как полагается и делает перенос строки. Что ты делаешь дальше? Эскейпируешь \r\n и получаешь \\r\\n. Соответственно, в теге <pre>, выводя результат, получаешь:
Строка 1\r\nСтрока 2
Потому что вот это \\r браузер воспринимает как заэскейпированный слэш+буковка r Так и выводит. Прям, как попросили. То же самое с \\n...
И в базу у тебя пишется то же самое. И выводится, соответственно. Ты просто от real_escape_string хочешь добиться чего-то прямо противоположного тому, что она должна делать Ты возьми и запиши в базу просто как есть, без эскейпирования. И удивишься, потому что твоя проблема неожиданным образом решится
Строка 1\r\nСтрока 2 - так и записывает в БД, в таком виде и выводит....
Дело таки в real_string, но почему?....
Простите, щас, может, тупану, но может, и нет. А задача у real_escape_string какая? Экранировать спецсимволы, в тч и nr. Она это и делает. Они там, скорее всего с двойным слэшэм в базу и записываются. При выводе в браузер два слэша дают один на экран и потом n или r. Чтобы картину четко увидеть надо через phpmyadmin в базу глянуть, а еще лучше выводить не в браузер, а в лог файл.
Если тупанул, то не судите строго.
Добавление. nr браузер все равно проигнорирует, поэтому если это все-таки из базы в браузер будет выводиться, надо nr сразу при записи заменять на html тэг br...
Еще добавление...
Хотя, конечно, отчасти, скорее всего тупанул-таки
Но суть в том, что в базе скорее всего два слэша. Может, два раза ескейпируется при записи где-нибудь еще?
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 329
