- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу

Тренды маркетинга в 2024 году: мобильные продажи, углубленная аналитика и ИИ
Экспертная оценка Адмитад
Оксана Мамчуева

В 2023 году Google заблокировал более 170 млн фальшивых отзывов на Картах
Это на 45% больше, чем в 2022 году
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
PHP умеет напрямую в код такой массив считывать.
Ну распарсить GET не проблема - это понятно.
Но чтобы принять эту конструкцию за массив.. Хм... Не знал, надо будет посмотреть на досуге.
Но даже если это и так, то всё равно конструкция мне кажется кривой. Значение-то одно на 3 переменных, и из твоего вывода видно, что оно для третьего, а первые два - неопределённы массивы.
Ну распарить GET не проблема - это понятно.
Но чтобы принять эту конструкцию за массив.. Хм... Не знал, надо будет посмотреть на досуге.
Но даже если это и так, то всё равно конструкция мне кажется кривой. Значение-то одно на 3 переменных, и из твоего вывода видно, что оно для третьего, а первые два - неопределённы массивы.
Странно я думал все знают об таком. Возможно я работаю с больших количеством самописных и всякого уже навидался.
Я не знаю конечно код, но могу предположить, что есть некий $filter_base=array в котором есть ВСЕ фильтры, в многомерном формате. Далее он сравнивается с GET массивом и на основе этого выводятся данные. Тем самым идёт сохранения целостности данных при сопоставлении массивов. И чтобы их сравнивать, массивы, надо сохранять общую структуру.
Но чтобы принять эту конструкцию за массив
Ну если в форме инпуты имеют вид
<input name="filter[selected][16][0]">
то результат отправки будет именно такой. Обычное дело же.
результат отправки будет именно такой. Обычное дело же.
Ну не знаю насколько обычное - в стандарте url нет же квадратных скобок (и на кой так именовать элементы форм - я могу только догадываться).
А я да, не знал этого. Мне в целом не так много приходилось общаться с многомерными массивами, но вообще никогда через get с ними не работал и нигде такого не встречал.
на кой так именовать элементы форм - я могу только догадываться
Я думаю, без труда догадаешься:
Я думаю, без труда догадаешься:
Неа. Я вижу это бредом (ну и тут не многомерка).
Предпочитаю понятную схему:
<form action="https://site.com">
<label>red<input type="checkbox" name="red"></label>
<label>green<input type="checkbox" name="green"></label>
<label>blue<input type="checkbox" name="blue"></label>
<label>black<input type="checkbox" name="black"></label>
<input type="submit" value="Go">
</form>
Единственное где могу представить - в какой-то генерёнке.
Я думаю, без труда догадаешься:
Не правильный пример.
Надо вот так:
Считывается массив color и идёт с ним работа. Это нужно когда нет явного количества элементов и они создаются динамически. Создавать под каждый вариант отдельную переменную, уж извольте.
Я вижу это бредом (ну и тут не многомерка).
Насчёт многомерки - это к теме о квадратных скобках не имеет значения, поэтому простейший случай. Многомерный массив получится при вложенных категориях, типа одежда->брюки->размер.
Бредом это только ты видишь, это часто бывает удобно, правда я на практике практически не встречал вложенность больше, чем name[0][0].
В твоём примере не видно, что это фильтр именно по цвету - а реально удобнее, когда на обработчик данных приходит поле, из названия которого видно, что обрабатываем. То есть в моём примере мы делаем поиск по цвету, заложив в обработчик поиск по "color", и значение поля может быть любым, добавляемым по необходимости. В твоём же примере в обработчик надо передавать закрытый список значений цвета.
Другое дело, что обычно, если такой многомерный фильтр нужно вывести в адресную строку, то лучше делать его обработку, заменяя всякие спецсимволы дефисами или подчёркиваниями. Если программист не ленивый.
В твоём примере не видно, что это фильтр именно по цвету
В реальном коде всё видно и понятно.
когда на обработчик данных приходит поле, из названия которого видно, что обрабатываем.
Не поверю что цвет кто-то может обрабатывать как цену или материал...
В обработчик всегда будет браться только то что нужно. Ну и если кто-то сильно волнуется о совпадениях имен переменных можно использовать именования типа "сolor_red". (Я напр. давно привык именовать переменные уникальными именами)
Я напр. давно привык именовать переменные уникальными именами
Ну на любителя. Кто-то привык постоянно мудрить с уникальными именами, а кто-то привык писать универсальный код и не заморачиваться с тем, кому какая блажь с серо-буро-малиновым цветом в голову придёт.