Что имеем: 

html странницу(сгенерённую php скриптом), представляющуюю собой список форм вида:



Как видите, эта форма представляет собой отображение  данных одной записи некой таблицы в некой базе данных. Кнопка OPEN - "открывает" объект, кнопка UPDATE - вносит изменения, кнопка DELETE стерает его из базы данных.
И таких форм у нас неограничено много.

Чего мне не хватает для счастья:

Хочу Ещё одну кнопочку типа "UPDATE ALL" внизу страницу позволяющую изменять данные сразу в нескольких запписях.

Вот и хочу знать - возможно ли  несколько форм, объеденить в другую форму, отправляющую данные сразу всех форм.. как то дифференцируя их? 

И какие пути реализации могли вы предложить?(Надеюсь, господа Модераторы не посчитают это вторым вопросом  )

В одну объединить, на сколько я знаю, нельзя, хотя бы из-за соображений, что параметр у формы action может быть только один. Но можно создать (собрать) массив из всех, присутствующих на странице форм (form[]) и делать с ними все, что заблагорассудится - http://www.w3schools.com/htmldom/dom_obj_document.asp. Если же менять параметры в динамическом режиме, то дело здесь не обойдется без AJAX .

Ты скрипт PHP переделать можешь?

Конечно могу  

тогда сделать как предлагал ilyaILF не составит труда

идея скажем такая:

называем элементы в соответствии с их id, потом на сервере обработка загон всех строчек в БД

Форма в любом случае должна быть одна, это, надеюсь, очевидно.

А поля для данной структуры я бы предложил называть так, чтобы на сервере можно было проходить по ним, как по массиву - я бы предложил такое:

Тогда при нажатии UPDATE ALL можно будет легко пробежаться по $_POST['obj'], и для каждого его элемента вызвать стандартную процедуру обновления (как и для единичного объекта). Если же $_POST['CMD'] является массивом с единственным значением - проапдейтить (удалить) следует лишь объект с соответствующим ID.

Почему форма, вносящая изменения в БД, должна иметь тип POST, а не GET, надеюсь, объяснять не надо?

Это сообщение отредактировал(а) SelenIT - 3.3.2008, 18:47

ilyaILF,
Проэкту ещё рано быть AJAX-приложением. На тему использования Jawascript  - подумаем  .

bars80080,

Я думал о таков варианте, но смущают вопросы обработки имен переменных

SelenIT,

Всё таки, после С++ под x86, php (под php5_module?  )  воспринимаешь не так как стоило бы.
Я бы просто не додумался) - пойду снова штудировать основы php.

GET использовал лишь потому что не использовал POST - на данном этапе всё происходи на локальной машине и причин, подталкивающих к использованию POST, я к сожалению   не вижу.

Id использовался для работы кнопки OPEN, и кажется он не отомрёт. Дело в том что на странице присутсвует список элементов не с полным набором id. Перебирать массив по id - неудобно.

Вероятно результат будет выглядеть так:



Над выбором между

ещё подумаю.

Спасибо, конкретно SelenIT и всем остальным не в меньшей степени.

Конечно не отомрет - он просто "перекочевал" в индекс каждого поля, относящегося к соотв. объекту... ;)


С каких пор foreach стал неудобным? По-моему - самое то...


GET-запрос - это ссылка, ссылки имеют обыкновение кешироваться (в проксях, в history браузеров...), кто-нибудь (юзер или прога) может попытаться загрузить ссылку еще раз... например, на UPDATE всех полей полугодовой давности . Не говоря о том, что GET гарантированно может передавать не более 2047 байт (в IE, а через некоторые прокси - и того меньше), обновление всех объектов в этот лимит вряд ли втиснется...

Добавлено @ 21:46

Имхо, проверять значение заведомо известной переменной все же проще, чем писать кучу if-ов для ловли неизвестной... но решай сам 

Это сообщение отредактировал(а) SelenIT - 3.3.2008, 21:48

Спасиб ещё раз, продолжаю психологический переход на php)

суть конечно у SelenIT, серьёзней

но никаких проблем априори возникнуть не может /для примера с именами name250/

при обработке массива $_POST:

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

bars80080, имхо, некрасиво и искусственно это как-то. К тому же по смыслу тут у нас именно массив объектов (асс. массивов), PHP предоставляет средства работы с таковым - почему бы не заюзать их напрямую? Вариант с параллельными массивами (name[250] - out[250] и т.д. для каждого имени поля) тоже допустим, но, имхо, массив ассоциативных массивов удобнее - с ним можно единообразно (одной процедурой) обрабатывать как единичный, так и множественный апдейт (соответственно, без цикла и в цикле foreach по id), с параллельными же массивами понадобится как минимум дополнительная проверка соответствий...

Это сообщение отредактировал(а) SelenIT - 4.3.2008, 12:33

да нет, это я ответил на ремарку SkyCoderа, что его смущает процесс обработки

понятно, что твой вариант удобнее, просто почему с каких-то пор (наверно, когда ещё много чего не получалось) я не люблю массивные имена и потому их не использовал