Народ, вот решил тут сделать знач страничку администрации пользователей. На странице табица, в ней столбцы пользователь, пароль, мыло, и четвертый столбец - кнопка удалить.
Вот как бы порациональней сделать так чтобы при нажатии удалялся данный пользователь.

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

при заполнении таблицы кнопка создается так...


То есть кнопк называются Del1, Del2, Del3  и т.д.

а в начале страницы 



То есть начинаем тупо перебирать все возможные варианты, а не нажимали ли эту кнопочку, а эту?.. и так все их перебирает.
Ну рабочий спосо в приницпе, но для 100-200 пользователей. а если их будет тысяч 5?
Вот и задумался...
Подскажите плис. может кто что подобное делал/видел.

чекбокс или радиобаттон и одна кнопка
потом проверять значение чекбокса
и сделать постраничный вывод, если пользователей станет много

О, пасибки, насчет радтобатона намана так.

лучше чекбокс + confirm из яваскрипта + постраничность 8-)
использую, только рад

а почему бы вместо кнопки не сделать ссылку? типа "?action=remove&id=2115"
ссылки же можно при помощи стилей оформить хоть в кнопки, хоть в ещё что-то. 

skyboy, потому что это все-таки удаление. Если какой-нибудь шальной робот или прога типа Google Desctop Index'а, по случайному недосмотру, пройдется по таким ссылкам - будет очень грустно. Тут нужен именно POST, т.к. в результате данные на сервере меняют свое состояние. А если ссылку можно стилизовать под кнопку, то ведь и кнопку можно стилизовать под ссылку тем же CSS...


shurup_312, разве не логичнее наоборот - имя у кнопок одно и то же, а значения разные и соответствуют искомым id?
На худой конец - name="Del['.$i.']" и на сервере что-то вроде

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

Основная проблема с множественными одноименными параметрами заключается в семантике серверного API. Если мы примем за данность, что имена параметров уникальны, то обращение get($_POST['input_name'] имеет четкий и понятный смысл: если параметр присутствует, мы получаем его значение, если нет - получаем null (ну или что там в ПХП).

Теперь сделаем допущение (совершенно валидное с точки зрения HTTP), что параметров с одинаковым именем может быть несколько. Ну и как нам тогда интерпретировать выражение get($_POST['input_name']? Анализировать тип результата на предмет массива? Коряво, много мусорного кода.

Мне могут возразить, что разработчик сам знает, какие параметры одиночные, а какие множественные. Ну так я вас обрадую: это ровно до тех пор, пока вы работаете с каждой формой индивидуально. А если попытаетсь надстроить над этим какой-то более общий слой, то сразу все грабли и вылезут наружу.

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

Так штааа...

Добавлено через 6 минут и 53 секунды
Да, а что касается:



то тут надо немного по-другому. Ты ведь выводишь юзеров постранично? Не все 5 тысяч за раз? Ну и вот, тогда и чекбоксов на удаление приедет не больше, чем юзеров на странице. Вот по ним (параметрам) и надо пробегаться, и смотреть на соответствие паттерну 'Del.N'. Так что ничего страшного нет.

Stampede, ну если foreach($_POST['controls_array'] as $control_id => $control_value) - это "много мусорного кода", а определять элемент "на ощупь" циклом с проверкой соответствия паттерна - это ничего страшного... то PHP-шность моего мышления, наверное, действительно неизлечима .

Кроме того, в данном случае, имхо, делать одну кнопку submit и массив радиокнопок либо несколько одноименных кнопок submit с разными value -

Только в варианте с массивом кнопок юзеру нужно сделать на один клик меньше...


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

Да, еще один PHP-специфичный нюанс: насколько я могу судить, с точки зрения запроса-то del[1] и del[2007] - именно разные имена, и если разработчик ждет их по одиночке, ничто не мешает обращаться сразу к $_GET['del'][1] и $_GET['del'][2007] (да, нотация чуть меняется, но единообразно). Так что, имхо, семантика серверного API в этом случае не страдает. А возможность перебрать все поля вида del[XXX] тем же foreach-ем - это как бы дополнительный бонус языка, по сути аналогичный перебору с проверкой по паттерну, только, имхо, более удобный...

Это сообщение отредактировал(а) SelenIT - 24.10.2007, 22:46

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

Кстати, множественные значения могут также приехать из списка (select) с множественным выбором, и с этим в плане разграничения на уровне имен параметров уж точно ничего не поделаешь.

В общем, disregard 

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

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

В целом согласен, но как же авторизация? 

С тем же гуглевским десктопом, если я ничего не путаю, как раз в том и была проблема, что он ходил по ссылкам со всеми текущими правами юзера (разумеется, исключительно чтобы упорядочить их для его же удобства, как предполагалось) - в итоге от пользователей систем с подобным интерфейсом посыпались сотни жалоб на потерянную без их ведома информацию. И главное: зачем сознательно выбирать метод, не предназначенный для этой задачи и потому требующий дополнительных усилий по обеспечению его надежности, когда, что называется, за те же деньги доступен другой метод, не требующий таких усилий? 

Пожалуй, незачем. Видимо, я просто выпендривался. 

Мда, логично. Хорошо, когда в споре рождается истина, а не пучки выдернутых у оппонентов волос 

ЗЫ: Есть повод кое-что порефакторить... Впрочем, это достаточно тривиально.