Javascript.RU

Создать новую тему Ответ
 
Опции темы Искать в теме
  #21 (permalink)  
Старый 03.05.2017, 16:32
Профессор
Отправить личное сообщение для laimas Посмотреть профиль Найти все сообщения от laimas
 
Регистрация: 14.01.2015
Сообщений: 12,990

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

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

В третьих, ваша модель должна ожидать JSON, декодировать его. Вот только какой в этом смысл, если без такого преобразования остальные поля формы передаются же серверу, разве нельзя отправить просто набор и полей характеристик?
Ответить с цитированием
  #22 (permalink)  
Старый 03.05.2017, 16:32
Аспирант
Отправить личное сообщение для Scantraxx Посмотреть профиль Найти все сообщения от Scantraxx
 
Регистрация: 11.12.2016
Сообщений: 47

что я только что заметил, так это то, что в dev tools мои отправляемые данные все есть, но до сервера почему-то не доходят
Ответить с цитированием
  #23 (permalink)  
Старый 03.05.2017, 16:40
Профессор
Отправить личное сообщение для laimas Посмотреть профиль Найти все сообщения от laimas
 
Регистрация: 14.01.2015
Сообщений: 12,990

Вот именно, поля формы можно отправить как есть, без всяких json преобразований. Вопрос только в том, что ожидает сервер и как эти данные обрабатывает.
Ответить с цитированием
  #24 (permalink)  
Старый 04.05.2017, 10:57
Аспирант
Отправить личное сообщение для Scantraxx Посмотреть профиль Найти все сообщения от Scantraxx
 
Регистрация: 11.12.2016
Сообщений: 47

Все таки проблема в отправке. Вышло отправить "ручками" на сервер данные в таком виде:
<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" />


А если я захочу удалить какой-то из добавленных? Есть способы какие-то?
Ответить с цитированием
  #25 (permalink)  
Старый 04.05.2017, 11:24
Профессор
Отправить личное сообщение для laimas Посмотреть профиль Найти все сообщения от laimas
 
Регистрация: 14.01.2015
Сообщений: 12,990

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

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

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


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

Последний раз редактировалось laimas, 04.05.2017 в 11:49.
Ответить с цитированием
  #26 (permalink)  
Старый 04.05.2017, 11:52
Аспирант
Отправить личное сообщение для Scantraxx Посмотреть профиль Найти все сообщения от Scantraxx
 
Регистрация: 11.12.2016
Сообщений: 47

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

Характеристики разные, допустим велосипедная рама:вес, цвет, углы различные и т.д.
Ответить с цитированием
  #27 (permalink)  
Старый 04.05.2017, 12:36
Профессор
Отправить личное сообщение для laimas Посмотреть профиль Найти все сообщения от laimas
 
Регистрация: 14.01.2015
Сообщений: 12,990

Сообщение от Scantraxx
не хочет он так приниматься, возможно потому, что я на в ходе в контроллер принимаю модель, а не коллекцию
А вы в любом случае отправляет коллекцию, которая описывается согласно типу отправляемых данных 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
вес, цвет, углы различные и т.д.
Походу получается, что ваша таблица характеристик будет страдать избыточностью.

Последний раз редактировалось laimas, 04.05.2017 в 13:11.
Ответить с цитированием
  #28 (permalink)  
Старый 04.05.2017, 13:14
Аспирант
Отправить личное сообщение для Scantraxx Посмотреть профиль Найти все сообщения от Scantraxx
 
Регистрация: 11.12.2016
Сообщений: 47

Сообщение от laimas Посмотреть сообщение
Походу получается, что ваша таблица характеристик будет страдать избыточностью.
Ну я специально перед проектировкой архитектуры пошуршал инет и там был предложен именно такой способ. С удовольствием выслушаю советы, как сделать лучше. У меня интернет-магазин велозапчастей, там около 40+ категорий, а это, если разбивать все на отдельные таблицы, все те же 40+ новых таблиц, что выходит весьма емко.
Ответить с цитированием
  #29 (permalink)  
Старый 04.05.2017, 13:36
Профессор
Отправить личное сообщение для laimas Посмотреть профиль Найти все сообщения от laimas
 
Регистрация: 14.01.2015
Сообщений: 12,990

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

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

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

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

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

https://support.microsoft.com/ru-ru/...ization-basics
https://habrahabr.ru/post/254773/
Ответить с цитированием
  #30 (permalink)  
Старый 04.05.2017, 13:40
Профессор
Отправить личное сообщение для laimas Посмотреть профиль Найти все сообщения от laimas
 
Регистрация: 14.01.2015
Сообщений: 12,990

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



Опции темы Искать в теме
Искать в теме:

Расширенный поиск


Похожие темы
Тема Автор Раздел Ответов Последнее сообщение
Динамическое добавление форм dalexra51 Элементы интерфейса 1 12.06.2015 11:05
Удаление / добавление JSON Alexander Belov Events/DOM/Window 16 01.05.2015 23:51
Формирование json через for -=1100=- Библиотеки/Тулкиты/Фреймворки 2 15.05.2014 09:12
динамическое добавление и редактирование полей Jquery nikolaymac jQuery 12 09.09.2013 07:53
Добавление и удаление полей в форму anoth3r Events/DOM/Window 1 11.09.2009 15:10