P.S. Посоветовал бы потихоньку забывать про навешивание событий элементам в таком синтаксисе, какой вы используете сейчас, а использовать метод on(), а еще лучше - с делегированной обработкой событий:
Как-то у вас всё запутано.
1. К функции вы всё-таки не обращаетесь. Она отрабатывает на странице, к которой идет ajax-запрос.
2. Разберем ваш путь '/data/fun/funTest'. Или же у вас на сервере присутствует физически директории по данному пути и в папке funTest есть файл index.php, или же вы используете mod_rewrite и запрос переадресовывается на handler. Где истина?
3. Могу попробовать протелепатировать и предположить, что js-код который вы показали выше, прописан в самом файле test.php. Если это так, то вынесите его в отдельный файл.js, подключите ко всем страницам, где он нужен, "запакуйте" в функцию и отлавливая необходимые события, вызывайте ее, передавая параметры.
у меня квадратные скобки в массиве, кавычки использовать немогу
Даже не знаю, что и сказать на это... Это вы решили, после того, как вывели массив на экран через print_r() или var_dump()? Дабы определиться, сделайте следующее: упакуйте ваш массив в json-строку и покажите. Т.е. таким образом:
Поправочка - это не ошибка в моем примере, а вы не указали в вопросе, что сортировка нужна с сохранением ключей. Но и это не проблема. Замените usort() на uasort().
На выходе - массив содержащий возможные сгенерированные пути или false, если таковых не оказалось. Если вы знаете, что такой путь может быть только в единственном экземпляре, то ответ функции можно и не собирать в массив.
Да, за исключением одного случая, данные нужно будет извлекать одним запросом. В таблице поля типов INT, VARCHAR, TIMESTAMP, никаких полей типа TEXT, BLOB etc - нет. Посему, объем данных большим не будет.
В общем, как я и планировал, буду делать одной таблицей. Просто впервые сталкнулся с такой задачей и не был уверен в правильности своих догадок, т.к. обычно делаю структуру БД таким образом, что всё разложенно аккуратно "по полочкам", а не одним большим скопом.
Теоретически, для такой задачи, можно использовать LocalStorage. Сравнивая с теми же cookie, в которых можно сохранить до 4Кб информации, в LocalStorage можно хранить около 5Мб. А это, по сути, достаточно, чтоб сохранить вообще всю страницу целиком. Но такой подход не всегда будет приемлем. Если вы генерируете какие-либо дополнительные элементы на странице и хотите оставить текущую структуру после обновления, то более логичным было бы использования хэша. Напр., нажал юзер на кнопку "Показать блок", добавили хэш к URI - site.ru/something/page.html#show-block. Вам остается отслеживать присутствие хэшей и, в зависимости от результата, запускать ту или иную функцию в JS.
Приветствую! Хотел посоветоваться по такому вопросу - есть анкета, количество заполняемых полей ~70+, теоретически их можно разбить на логические блоки, которые и записывать в отдельные таблицы БД (MySQL). Но имеет ли смысл это делать? Или же не париться и записать всё в одну таблицу? Вопрос - с точки зрения производительности. Сам я склоняюсь к последнему (одна таблица), но хотел выслушать другие мнения.
Приветствую!
Вопрос состоит в том, сколько рационально выделять памяти под memcached? Я понимаю, что под разные цели, выделяется соответствующее количество, но так как это мой первый опыт в работе и настройках своего VDS, то хотелось бы понять принцип, по которому производиться такая операция.
В настоящий момент - VDS с 1Гб ОЗУ, используется ~980Мб, ~720Мб закешировано и свободно - плюс-минус 20 метров. Если взять для примера сайт, на котором в пике будет ~100 человек онлайн, на самой "тяжёлой" странице выполняется 7 запросов к БД, результат как минимум одного из запросов и планируется кешировать.
Я не жду конкретных цифр, но если укажите хоть примерный диапозон, то буду благодарен. И дело ясное, что процессе, я уже буду корректировать эти значения, но для начала, надо хоть как-то определиться.
Речь видимо в том, что вы не внимательно читали. Запрос, с использованием ключевого слова "IGNORE", не вызовет никаких исключений, ошибок и т.д., потому как строки, имеющие дублирующиеся ключи PRIMARY или UNIQUE в этой таблице, будут попросту проигнорированы, при этом не будет прекращено выполнение.
Безусловно использую, только в исключения это не попадает, т.к. не считается ошибкой выполнения, а без IGNORE ошибка выстраивается в ответ ajax-запроса и выводит из строя всю дальнейшую работу сайта. Да Бог с ним, я так подумал, что одним запросом больше - на скорость работы не повлияет, к тому же запрос простейший и по уникальным полям. А то "программистская паранойя" иногда берет верх над здравым смыслом
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 298
Даже не знаю, что и сказать на это... Это вы решили, после того, как вывели массив на экран через print_r() или var_dump()? Дабы определиться, сделайте следующее: упакуйте ваш массив в json-строку и покажите. Т.е. таким образом:
