Есть множество свойств которые добавляются пользователем, и каждое из которых имеет свой уникальный ID, признак будет ли оно использоваться (Checkbox) и значение. 
Необходимо дать пользователю возможность на одной странице редактировать все свойства одновренменно либо по 10, 20, 50, 100 и т.д. свойств одновременно, т.е. выводить список состоящий из перечня свойств и дать возможность пользователю проставить "птички" будет ли свойство использоваться  и задать их значения. Далее, нажатием кнопки, все значения сохраняются и переходим к следующим значениям.
Все, что касается вывода я реализовал (Создается форма, в нее последовательно вывожу все свойства (Checkbox) и их значения). Как реализовать постраничное отображение тоже знаю, а вот как сохранить эти значения? Предпологаю, что нужно правильно проименовать эти значения, но как их обрабатывать?
Подскажите, пожалуйста, как можно реализовать такой механизм?

Как мне кажется, проще всего завести массив чекбоксов со значениями твоих этих свойств:


Когда PHP скрипт получит значения формы, то в $_POST["prop"] будет находиться массив с выбранными (отмечеными) своствами - невыбраные свойства в этот массив не попадут. Соответственно, все, что нужно будет сделать - это проверить, находиться ли нужное свойство в этом массиве. Например так:


Хранить значение в базе можно в текстовом поле, выполнив serialize($props). Когда нам нужно будет добыть значения из базы, нужно выполнить serialize() строки, полученой из базы. А потом if (in_array([имя параметра],$props)) .... Ну и т.д.

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

Благо, у автора вопроса не должно возникнуть таких идей, поскольку параметр хранится в одной строке со значением.

Аргументы?

Добавлено через 1 минуту и 19 секунд
Сериализованый вид очень удобен тем, что без труда можно добавить или убрать какое-то значение. Не все базы одинаково полезны. К тому же, не в разделе БД мы.

... а как передать не выбранные свойства?

MakNik, они тебе не нужны. вполне достаточно отсутствия. у тебя же не одни чекбоксы, а еще и текстовые инпуты, которые придут все. Вот их и перебирай.

А зачем? У тебя есть массив отмеченых! Когда в коде будешь проверять включено ли нужное свойство - достаточно будет делать in_array() и все. И не надо страдать хренью.

... что-то не получается... мало опыта у меня...
Приведите, пожалуйста, пример   
Допустим у меня генерируется такая форма:


как обработать в PHP эту форму?

Для начала сделай print_r($_POST)
чтобы глазами посмотреть, что у тебя в переменных. это вообще очень важно - представлять себе, что лежит в переменных.

Там ты увидишь три массива. в частности - массив $_POST['select']
Его можно перебирать в цикле, получая пары ключ - значение. Ключ совпадает с ключом других массивов - следовательно, легко проверить их существование.

а вот поле catn в форме передавать бессмысленно

MakNik, во-первых, реальных пример я тебе уже дал, нужно проявить хоть немного внимательности к теме.
Во-вторых (по сабжу):
Так неправильно. Даже синтаксически неверено.

Я же писал, что должны отличаться ЗНАЧЕНИЯ чекбоксов, а не их имена. Т.е. в твоем случае надо так:

Так тоже можно, на самом деле. PHP и это преобразует в массив. Хотя брать значения атрибутов HTML в кавычки желательно всегда - хотя бы во избежание сюрпризов из-за шального пробела.

Неправильно!=не будет работать. Работать этот вариант, безусловно будет. Вот только интересно, зачем в даном случае для 1го, 2го, 3го и т.д. прописывать идентификаторы? По-моиму это лишнее телодвижения. А то, что в кавычки нужно брать - так это элементарные правила хорошего тона.

В данном случае, пожалуй, незачем. Но бывают (хоть и редко) задачи, когда удобнее передавать одновременно и id, и значение - например, при уточнении уже отфильтрованного по каким-то критериям диапазона. А "синтаксически неверно" - имхо, это как раз "не работает" (а-ля Parse Error).


Не только хорошего тона, но и страховки от сюрпризов.

Это сообщение отредактировал(а) SelenIT - 17.1.2008, 15:00

В данном случае, как раз, есть, зачем - проверять через empty, а не array_search

Вот что получилось:


Я правильно сделал или есть еще подводные камни?