И какой смысл в этом коде? Во-первых по коду выше у вас нет полей с классами details_value и details_name, это имена полей, поэтому $(this).find(".details_value") ничего не вернет.
Во-вторых, после получения данных полей и формирования JSON нужно эти поля удалять из формы. В третьих, ваша модель должна ожидать JSON, декодировать его. Вот только какой в этом смысл, если без такого преобразования остальные поля формы передаются же серверу, разве нельзя отправить просто набор и полей характеристик? |
что я только что заметил, так это то, что в dev tools мои отправляемые данные все есть, но до сервера почему-то не доходят
![]() |
Вот именно, поля формы можно отправить как есть, без всяких json преобразований. Вопрос только в том, что ожидает сервер и как эти данные обрабатывает.
|
Все таки проблема в отправке. Вышло отправить "ручками" на сервер данные в таком виде:
<input name="detail[0].details_name" type="text" /> <input name="detail[0].details_value" type="text" /> <input name="detail[1].details_name" type="text" /> <input name="detail[1].details_value" type="text" /> <input name="detail[2].details_name" type="text" /> <input name="detail[2].details_value" type="text" /> А если я захочу удалить какой-то из добавленных? Есть способы какие-то? |
Проблема не в отправке, а в именовании полей формы: а) вашим контроллером они оговаривают и ожидаются; б) именоваться поля должны как элементы массива, при этом жестко указывать индекс возможно и не надо.
Можно конечно удалять, только у вас нужно удалять пару. Разберитесь сначала с именованием, вот так будет приниматься массив: <input name="detail[].details_name" type="text" /> <input name="detail[].details_value" type="text" /> .... На засыпку - а какие характеристики описываются? |
Цитата:
Характеристики разные, допустим велосипедная рама:вес, цвет, углы различные и т.д. |
Цитата:
Например в РНР я могу сам разбирать RAW данные, но проще использовать готовое, которое обеспечивается языком - в нем данные формы попадут в массив $_POST (отправка файлов только методом POST), а информация о загруженных файлах в массив $_FILES. При этом парсер будет поступать так - если к примеру отправляется три поля формы с именами "а", то в массиве окажется только одно значение, последнего поля. И это логично - массив не может иметь одинаковых индексов/ключей, а предписанием парсеру получить все поля является указание принадлежности имен к массиву "а[], "а[]", "а[]". В этом случае парсер автоматически поместит значения полей в массив "а" соответственно под индексами 0, 1, 2. То есть указывать жестко индексы в именовании не требуется. Такое именование позволяет получать на сервере вложения элементов формы (группировка) определяемые разработчиком самой формой, то есть многомерные массивы. А необязательность указания индекса позволяет легче оперировать элементами на клиенте, например тогда, когда серверу необходима последовательность индексов от 0 до ... К примеру с вашей жесткой индексацией при удалении произвольных индексов (полей) как поведет себя контроллер? Исходя из этого условия в среде РНР нельзя именовать выпадающий список со множественным выбором не указывая его имя как "name[]", иначе разработчик получит значение только последней выбранной в списке опции. Похоже этим же условием руководствуется и ваш контроллер. Проверьте не будет ли ошибок с такими полями: <input name="detail[3].details_name" type="text" /> <input name="detail[3].details_value" type="text" /> <input name="detail[8].details_name" type="text" /> <input name="detail[8].details_value" type="text" /> У вас нужно добавлять и удалять по паре полей, и реальный код такого удаления будет сильно зависеть от html-структуры. Надо сначала с этим определиться, можно конечно и так поступить: <input name="detail[0].details_name" type="text" /> <input name="detail[0].details_value" type="text" /> <input type="button" value="Удалить" /> <input name="detail[1].details_name" type="text" /> <input name="detail[1].details_value" type="text" /> <input type="button" value="Удалить" /> Но такая структура не удобна ведь с точки зрения информативности. Тут либо каждые два поля + кнопка удаления в одну линию, либо вложенные в родительский элемент имеющий визуальные границы. Подумайте сначала над этим. Цитата:
|
Цитата:
|
Цитата:
"Колесо", "100 руб.", "ООО Автозапчасть", "1.jpg" "Колесо", "100 руб.", "ООО Автозапчасть", "2.jpg" "Колесо", "100 руб.", "ООО Автозапчасть", "3.jpg" .... Да, все в одной таблице, но при этом объем этой таблицы неоправданно возрастает из-за избыточных данных - повторяющихся описаний основных характеристик товара. Тоже самое ожидается и вашей таблице характеристик, так как, например, характеристику "цвет" могут иметь все ваши запчасти, и ее значение "черный" также. А по уму основная таблица должна иметь связь с таблицей описывающей уже определенные характеристики (набор характеристик) через внешнюю таблицу связей. Если такой набор фиксированный, динамически неизменяемый, то выгоднее такие характеристики как цвет, вес, размер, (их значения) описывать в основной таблице. При проектировании баз данных руководствуются принципами нормализации: https://support.microsoft.com/ru-ru/...ization-basics https://habrahabr.ru/post/254773/ |
Принимает ваш контроллер произвольные индексы (по идее должен)?
|
Часовой пояс GMT +3, время: 23:36. |