-
Notifications
You must be signed in to change notification settings - Fork 205
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Упорядочение параметров в URL #25
Comments
Обоснованный кейс, как решение предлагаю добавить возможность принимать в качестве параметров СписокЗначений - это упорядоченная структура, в качестве имени параметра использовать Представление, в качестве значения - Значение |
Попробовал добавить функционал, уперся в В ЗаполнитьПараметрыЗапроса()
Непонятно зачем формируется массив, по идее значением может быть только строка, возможно сериализованная. |
Может быть несколько значений
|
Если параметры запроса это соответствие массивов
То почему присваивается строка?
Которая получается из
Так же "хак" с добавлением в массив непонятен. Connector/src/CommonModules/КоннекторHTTP/Ext/Module.bsl Lines 1848 to 1851 in 75b57af
Если нужно, то обозначить на входе что параметры передаются массивами. Если переделывать в список, то нужно убирать массивы вообще. |
https://stackoverflow.com/questions/1746507/authoritative-position-of-duplicate-http-get-query-keys Чаще всего к параметрам которые могут быть массивом добавляют суффик То, что появляется массив вдруг неожиданно - очень не удобно, конечно, такое разбирать потом. Кажется важно поддержать суффикс |
"чаще всего []" - это специфичный костыль из PHP 3/4, который автоматически это преобразует в массив. В современном PHP такое делать уже давно не принято. На мой взгляд Коннектор не должен автоматически создавать массив если ключ с суффиксом "[]" только один |
Ну P.S. Исходный issue все же про другое. Про кривые реализации серверной части, которые хотят строгий порядок параметров |
Для меня в этом пребразовании в массив больше всего не нравится то что непонятно можешь получить массив или нет. Нет спецификации. Нужно писать постобработчики для того чтобы выделать один элемент в массив из одного элемента, заранее заявить что параметр должен быть массивом нельзя. Это некомфортно. Какой то спецификации по тому нужно ли поддерживать порядок или нет я не нашел. |
Неудобство понятно, однако я продолжаю считать, что это не сфера ответственности библиотеки Коннектора. |
И я согласен что проблему "массива" надо выносить в отдельный тикет |
Добавить параметр, что все значения всегда массив или функцию, которая строку будет всегда в массив заворачивать |
Хорошее видео к теме нескольких одинаковых параметров в запросе: |
Увели нужный вопрос в другую тему ) Плохо, что нельзя самому собрать строку запроса в нужном порядке. Если б можно - вопрос частично закрылся бы. Я тоже начал себе переделывать ПараметрыЗапроса как структуру/соотвествие на упорядоченный массив/список, а потом плюнул... много переделок в библиотеке.
и когда важно, чтобы PARAM* шли по порядку, а порядок KEY* - без разницы. |
Было бы здорово приводить конкретные кейсы где это нужно: на каких сайтах или API порядок важен. Нужны конкретные примеры таких API
|
Битрикс же! (гореть ему в аду ;)) ). Каждый метод на свой лад. |
Честный знак Описание True API
Вариант хранения параметров массив структур или ТЗ |
Коннектор принимает в качестве параметров в URL структуру или соответствие, которые не гарантируют порядок следования элементов. Возникают проблемы при взаимодействии с API, для которых порядок параметров в URL имеет значение.
The text was updated successfully, but these errors were encountered: