Динамическое добавление полей и формирование JSON

[laimas]

И какой смысл в этом коде? Во-первых по коду выше у вас нет полей с классами details_value и details_name, это имена полей, поэтому $(this).find(".details_value") ничего не вернет.

Во-вторых, после получения данных полей и формирования JSON нужно эти поля удалять из формы.

В третьих, ваша модель должна ожидать JSON, декодировать его. Вот только какой в этом смысл, если без такого преобразования остальные поля формы передаются же серверу, разве нельзя отправить просто набор и полей характеристик?

[Scantraxx]

что я только что заметил, так это то, что в dev tools мои отправляемые данные все есть, но до сервера почему-то не доходят

[laimas]

Вот именно, поля формы можно отправить как есть, без всяких json преобразований. Вопрос только в том, что ожидает сервер и как эти данные обрабатывает.

[Scantraxx]

Все таки проблема в отправке. Вышло отправить "ручками" на сервер данные в таком виде:

<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" />

А если я захочу удалить какой-то из добавленных? Есть способы какие-то?

[laimas]

Проблема не в отправке, а в именовании полей формы: а) вашим контроллером они оговаривают и ожидаются; б) именоваться поля должны как элементы массива, при этом жестко указывать индекс возможно и не надо.

Можно конечно удалять, только у вас нужно удалять пару. Разберитесь сначала с именованием, вот так будет приниматься массив:

<input name="detail[].details_name" type="text" />
<input name="detail[].details_value" type="text" />
....

На засыпку - а какие характеристики описываются?

[Scantraxx]

вот так будет приниматься массив:

не хочет он так приниматься, возможно потому, что я на в ходе в контроллер принимаю модель, а не коллекцию

Характеристики разные, допустим велосипедная рама:вес, цвет, углы различные и т.д.

[laimas]

не хочет он так приниматься, возможно потому, что я на в ходе в контроллер принимаю модель, а не коллекцию

А вы в любом случае отправляет коллекцию, которая описывается согласно типу отправляемых данных enctype, который в вашем случае должен быть multipart/form-data. Серверный язык получая эти сырые данные (RAW) поступает так как ему предписано.

Например в РНР я могу сам разбирать 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="Удалить" />

Но такая структура не удобна ведь с точки зрения информативности. Тут либо каждые два поля + кнопка удаления в одну линию, либо вложенные в родительский элемент имеющий визуальные границы. Подумайте сначала над этим.

вес, цвет, углы различные и т.д.

Походу получается, что ваша таблица характеристик будет страдать избыточностью.

[Scantraxx]

Походу получается, что ваша таблица характеристик будет страдать избыточностью.

Ну я специально перед проектировкой архитектуры пошуршал инет и там был предложен именно такой способ. С удовольствием выслушаю советы, как сделать лучше. У меня интернет-магазин велозапчастей, там около 40+ категорий, а это, если разбивать все на отдельные таблицы, все те же 40+ новых таблиц, что выходит весьма емко.

[laimas]

если разбивать все на отдельные таблицы, все те же 40+ новых таблиц, что выходит весьма емко.

А почему тогда изображения у вас описываются в отдельной таблице, емко же? А если имена изображений помещать в основную таблицу, что получится? А получится следующее:

"Колесо", "100 руб.", "ООО Автозапчасть", "1.jpg"
"Колесо", "100 руб.", "ООО Автозапчасть", "2.jpg"
"Колесо", "100 руб.", "ООО Автозапчасть", "3.jpg"
....

Да, все в одной таблице, но при этом объем этой таблицы неоправданно возрастает из-за избыточных данных - повторяющихся описаний основных характеристик товара. Тоже самое ожидается и вашей таблице характеристик, так как, например, характеристику "цвет" могут иметь все ваши запчасти, и ее значение "черный" также.

А по уму основная таблица должна иметь связь с таблицей описывающей уже определенные характеристики (набор характеристик) через внешнюю таблицу связей. Если такой набор фиксированный, динамически неизменяемый, то выгоднее такие характеристики как цвет, вес, размер, (их значения) описывать в основной таблице.

При проектировании баз данных руководствуются принципами нормализации:

https://support.microsoft.com/ru-ru/...ization-basics
https://habrahabr.ru/post/254773/

[laimas]

Принимает ваш контроллер произвольные индексы (по идее должен)?