Обработка данных формы

@Bond 17 · Регистрация: 25.09.2012

Студворк — интернет-сервис помощи студентам

Здравствуйте.
Собственно вопрос в следующем - есть форма к примеру для отправки данных о человеке с двумя полями имя и телефон:

HTML5
1
2
<input type="text" name="name">
<input type="text" name="phone">

также должна быть кнопка добавить человека при нажатии на которую появляется еще одна пара таких же полей:

HTML5
1
2
3
4
<input type="text" name="name">
<input type="text" name="phone">
<input type="text" name="name">
<input type="text" name="phone">

Вопрос состоит в том - стоит ли во второй и последующий парах изменять атрибут name? то есть можно ли в обработчике извлечь инфу с двух полей с одним атрибутом name и как это сделать.

P.S На практике буде значительно больше полей, списков, чекбоксов и полей для отправки фалов (около 20).

@esculap_ra · 12.07.2014, 18:36

Стоит. Поля должны носить уникальные имена.

@Bond 17 · 12.07.2014, 18:53 **[ТС]**

Спасибо, уже разобрался - на самом деле не стоит. Если оставить так как я писал - name="name" то в масиве $_POST['name'] будет выводится последнее значение, но если атрибут name называть так name="name[]" то можно создавать хоть сотни таких же полей - в обработчике ими легко оперировать работая как с масивами

@esculap_ra · 13.07.2014, 01:45

В принципе, если обозвать массивом, то не нужно изменять. Но тебе нужно также и массив номеров телефонов. Лично я бы в таком случае предпочел бы в обработчике оперировать с уникальными полями, типа name1,name3 и т.п. Ну это уже на любителя.

@Bond 17 · 13.07.2014, 11:30 **[ТС]**

У меня получится отдельно массив имена, массив телефоны и т.д.
Думаю так лучше в виду того что полей будет много - больше 20, а при нажатии на кнопку добавить человека должно появляться еще 20 полей - мне проще считать предыдущие поля и записать (jQuery) чем считать, изменить значения атрибута name а потом еще в php обрабатывать.

Новые блоги и статьи Все статьи Все блоги /
Контроль заполнения и очистка дат в зависимости от значения перечислений Maks 12.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа "ПланированиеПерсонала", разработанного в конфигурации КА2. Задача: реализовать контроль корректности заполнения дат назначения. . .	Архитектура слоя интернета для сервера-слоя. Hrethgir 11.04.2026 В продолжение https:/ / www. cyberforum. ru/ blogs/ 223907/ 10860. html Знаешь что я подумал? Раз мы все источники пишем в голове ветки, то ничего не мешает добавить в голову такой источник, который сам. . .	Подстановка значения реквизита справочника в табличную часть документа Maks 10.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа "ПланированиеПерсонала", разработанного в конфигурации КА2. Задача: при выборе сотрудника (справочник Сотрудники) в ТЧ документа. . .	Очистка реквизитов документа при копировании Maks 09.04.2026 Алгоритм из решения ниже применим как для типовых, так и для нетиповых документов на самых различных конфигурациях. Задача: при копировании документа очищать определенные реквизиты и табличную. . .
модель ЗдравоСохранения 8. Подготовка к разному выполнению заданий anaschu 08.04.2026 https:/ / github. com/ shumilovas/ med2. git main ветка * содержимое блока дэлэй из старой модели теперь внутри зайца новой модели 8ATzM_2aurI	Блокировка документа от изменений, если он открыт у другого пользователя Maks 08.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа, разработанного в конфигурации КА2. Задача: запретить редактирование документа, если он открыт у другого пользователя. / / . . .	Система безопасности+живучести для сервера-слоя интернета (сети). Двойная привязка. Hrethgir 08.04.2026 Далее были размышления о системе безопасности. Сообщения с наклонным текстом - мои. А как нам будет можно проверить, что ссылка наша, а не подделана хулиганами, которая выбросит на другую ветку и. . .	Модель ЗдрввоСохранения 7: больше работников, больше ресурсов. anaschu 08.04.2026 работников и заданий может быть сколько угодно, но настроено всё так, что используется пока что только 20% kYBz3eJf3jQ

@esculap_ra 462 / 265 / 55 Регистрация: 22.08.2010 Сообщений: 1,204 Записей в блоге: 4
	12.07.2014, 18:36
	Стоит. Поля должны носить уникальные имена. 0

@Bond 17 7 / 7 / 2 Регистрация: 25.09.2012 Сообщений: 89
	12.07.2014, 18:53 [ТС]
	Спасибо, уже разобрался - на самом деле не стоит. Если оставить так как я писал - name="name" то в масиве $_POST['name'] будет выводится последнее значение, но если атрибут name называть так name="name[]" то можно создавать хоть сотни таких же полей - в обработчике ими легко оперировать работая как с масивами 0

@esculap_ra 462 / 265 / 55 Регистрация: 22.08.2010 Сообщений: 1,204 Записей в блоге: 4
	13.07.2014, 01:45
	В принципе, если обозвать массивом, то не нужно изменять. Но тебе нужно также и массив номеров телефонов. Лично я бы в таком случае предпочел бы в обработчике оперировать с уникальными полями, типа name1,name3 и т.п. Ну это уже на любителя. 0

@Bond 17 7 / 7 / 2 Регистрация: 25.09.2012 Сообщений: 89
	13.07.2014, 11:30 [ТС]
	У меня получится отдельно массив имена, массив телефоны и т.д. Думаю так лучше в виду того что полей будет много - больше 20, а при нажатии на кнопку добавить человека должно появляться еще 20 полей - мне проще считать предыдущие поля и записать (jQuery) чем считать, изменить значения атрибута name а потом еще в php обрабатывать. 0