Я тоже задумывался над этим. Пришел к выводу что правильно говорят, "Благими намерениями устлана дорога в ад".
Конечно можно завести таблицу с полями.
Конечно можно попытаться формализовать проверку форм, храня в базе табличку `fieldid`, `regexp`, `flag`, `error`, и брать нужные регулярки проверяя в цикле и записывать ошибки в массив. А потом поиметь кучу гемора, до последнего момента веря в то что это удобно.
Но. Полностью формализовать проверку всех форм нельзя. Т.к. мы придем к PHP-коду. Например, форма редактирования профиля у меня в двиге. Поле Текущий пароль не обязательно для заполнения если не нужно менять Пароль и/или E-Mail. Конечно можно завести флаг "needfillpassword" в таблице с полями, которое бы возвестило о необходимости ввода пароля при изменении этого поля. Но. Естественно вся универсальность теряется уже на таком простейшем примере. Поэтому мне куда проще обойтись PHP-кодом со старыми добрыми if'ами в большом количестве. Как, я думаю, и любому другому программисту (у меня получается одно поле - один-два if, чаще конечно 1).
Если делать "авто добавление полей" в сохраняемую, то встает вопрос как хранить сами данные, после их сохранения, т.е. мы добавляем поле "myfield" и нам нужно добавить колонку в таблицу, что само по себе плохой тонъ (изменение структуры БД скриптами), а если заводить ряд в таблице где хранятся данные по ID полей, то мы потеряем множество возможностей выборки да и это еще больший изврат.
Поэтому магические скрипты избавляющие от геморроя при создании форм лучше забыть, т.к. геморрой они только добавляют. Авторы обычно советуют создавать все формы только на их продуктах.
Может остаться сомнение и подумаете "а если делать авто добавление самостоятельных полей типа IM-идентификаторов, размера сисек и т.д.?". Ну допустим сделали скрипт который будет редактировать колонки таблицы, хранить в отдельной таблице регулярки как описано выше, форма будет строиться сама и т.д. Очень страдает гибкость, т.е. дизайнер не сможет разместить поля там где нужно, выделить какое-то поле подчеркиванием, и т.д. Но это полбеды, куда больше страдает гибкость когда мы эти поля будем доставать. Во-первых дизайн должен быть формализованый опять же (например, шаблон userinfo, я бы не смог разместить всё так как хочу), во-вторых выборка и т.д. Самое смешное если формализовать форму добавления полей.
Ведь ясно - программисту и дизайнеру проще добавить вручную. Это может быть полезно лишь пользователям, которым нужно работать с простой однотипной формой, например с формой Обратной связи, с её дополнительными полями. Там все элементарно уходит на почту, и никуда не сохраняется. Но опять же, я пока не видел человека который знает регулярные выражения и не способен сделать с формой что ему нужно. А если забить на проверку формы - зачем это нужно?
-~{}~ 21.08.06 06:46:
Kapacb
Это для ламеров. Нормальному программеру ничего не стоит сделать форму довольно быстро.
