Класс для рисования форм - нужен ли?

[Фанат]

Класс для рисования форм - нужен ли?

Есть много решений, которые превращают работу с формами в замкнутый цикл: сами нарисовали - сами обработали. HTML QuickForm, например.

Насколько вы считаете оправданным такой подход, ведь с абстрактной точки зрения тег <a> ничем не отличается от тега <input>, но первый мы выводим с помощью шаблона, а вторй - класса?

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

Ваше мнение?

 

[crocodile2u]

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

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

 

[Гравицапа]

Мне больше понравилась концепция помощников (helpers) в CakePHP.
Они вставляются прямо в шаблон и нужны по сути просто для более удобного ввода, например, элементов форм.

http://manual.cakephp.org/chapter/helpers

P.S. То есть валидацией они не занимаются...

 

[Sad Spirit]

Автор оригинала: Фанат
Насколько вы считаете оправданным такой подход, ведь с абстрактной точки зрения тег <a> ничем не отличается от тега <input>, но первый мы выводим с помощью шаблона, а вторй - класса?

Вообще-то теги отличаются, хотя бы тем, что в атрибуты тега <a> мы редко выводим результаты ввода пользователя.

Принцип разделения таки страдает, но вот что такое javascript, проверяющий форму, --- шаблон или код?

 

[Shturm]

Вообще это сложный вопрос.

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

Но с другой стороны - все операции с формой (отображение - проверка)
достаточно однообразны по сути своей, и что если поле было отображено,
то оно должно быть проверено строго определенным образом.
Отсюда появляется логичное желание централизовать все эти функции
чтобы не метаться в дальнейшем по всему скрипту если вдруг форма,
или какое-либо поле в ней изменится.

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

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

Главное отличие от QuickForm etc. - модель формы не содержит ни методов генерации html, ни методов валидации.
Это - всего лишь "конфиг", который к тому же умеет сохранять и отдавать данные формы и данные об ошибках.

Sad Spirit

что такое javascript, проверяющий форму, --- шаблон или ко

это - ненужная примочка в браузере клента

 

[Observer]

Re: Класс для рисования форм - нужен ли?

Лично меня не устраивает встроенная валидация, она усложняет решение таких задач, как проверка на уникальность введенного значения (типа "уже есть пользователь с таким логином") и другие нетипичные проверки. Поэтому провожу валидацию непосредственно в коде, принимающем данные формы.

Там, где нужно много форм с одинаковым оформлением (CMS), использую свой класс с xslt-преобразованием, т.е. шаблон формы определяется в отдельном xml-файле, в нем задаются поля, их заголовки, описания, является ли это поле обязательным для заполнения и т.д. (можно задавать и свои типы полей - наборы чекбоков, даты), к шаблону применяется xsl-стиль, который задает оформление формы. В классе поддерживаются подстановка значений, сообщения об ошибках с подсветкой полей.
Достоинства - быстрое создание новых шаблонов, соблюдение принципа разделения, можно использовать с любым шаблонизатором.
Ограничения - не самый быстрый (но для CMS вполне приемлемо + кэширование), изменение оформления требует знания XSL.

Интересно услышать мнения о таком подходе.

 

[ilkz]

Мне такой подход по душе.
Я и сам в своей CMS использую связку XML+XSLT, правда не для работы с формами, а для работы с шаблонами страниц.
Очевидный плюс такого подхода - действительно разделение кода и дизайна.
Не менее очевидный минус - сложность такого монстра, т.к. дизайнер должен знать XSL и XML в довесок.

 

[Romantik]

используя абстракцию я достигаю того что админ проекта управляет конфигурацией (файл, база, XML), в которой указываю все аттрибуты и правила и валидацию, как для PHP так и для JS а в шаблоне стоит цикл вывода полей (дизайнер тупо ставит этот цикл) + кеширование (все же поля не часто меняются) получается удобное сочетание и нет необходимости править шаблоны, скрипты.

 

[WP]

Я считаю что когда скрипт пишет программист, делает форму например регистрации пользователей, то следует делать обработку вручную (if'ами), ведь обычно проверка 1 поля - 1-2 строчки кода.

   if (!$users->validate_username(gpcvar_str($_REQUEST['username']))) {$errors[] = lang_cache_getmessage('ERR_INCORRECT_USERNAME_FORMAT');}
   elseif ($users->getbyname(gpcvar_str($_REQUEST['username']),TRUE)) {$errors[] = lang_cache_getmessage('ERR_USERNAME_ALREDY_IN_USE');}

Массив $errors хранит сообщения об ошибках.

$done = isset($_REQUEST['submit']) && sizeof($errors) == 0;

А в шаблоне выводим.

Не вижу смысла в формализации проверки форм, т.е. callback'ами и т.д. Усложнение жизни программиста.

Другое дело когда тупая секретарша хочет добавить поле "Удобное время для встречи" в форму обратной связи. В PHP-код ей лезть однозначно нельзя. Поэтому я думаю что удобно было бы хранить поля такой формы абстрактно от HTML где-нибудь в БД или в XML, как описал Romantik.

 

[master_x]

использую нечто типа helpers для отрисовки форм. для валидации данных использую callbacks и не жалуюсь.

 

[Bermuda]

Один из доводов это расширение множества элементов формы путем создания новых классов.
Что мы имеем на пространстве HTML? input, image, select, button, textarea и ... всё?
Используя библиотеку а-ля QuickForm можно создавать новые элементы форм, наследовать, расширять.
Прямая выгода для дизайнера форм. Захотел нарисовал пароль, захотел выбор цвета,
В качестве примера (не сочтите за рекламу)
QForm (не путать с QuickForm) от фрэймворка qcodo
Более того, сторонние разработчики уже понаваяли тучу классов расширяющих стандартные.
Например нужен новый элемнт формы, номер мобильного телефона в определенной стране, ну или номер счета в банке где деньги лежат. Расширяем класс Qtextbox - нате, новый элемент формы.
И не ломаем голову над написанием новых скриптов для валидации номера счета (который имеет определенный формат и контрольную сумму)

Про микроформаты, надеюсь, слышали?

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

 

[nerezus]

Не нужен.
Это работа верстальщика, а не программиста

 

[Bermuda]

Re: Класс для рисования форм - нужен ли?

Автор оригинала: Фанат
Но, с другой стороны, страдает принцип разделения шаблона и кода.

Есть удачные решения при которых код и шаблон разделяются посто превосходно.

 

[Фанат]

продолжай

 

[Bermuda]

Автор оригинала: Фанат
продолжай

Вот, например, калькулятор

Исходный код класса View идеологии MVC

Это исходный код шаблона

Обратите внимание, что код шаблона не содержит кода PHP кроме кусков типа

<?php $this->txtValue1->Render(); ?>

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

{SOME_VALUE}

Вдогонку:

QForms is a stateful, event-driven architecture for web-based forms, providing the display and presentation functionality.

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

 

[boombick]

Это работа верстальщика, а не программиста

+1
Я тоже считаю, что обработка формы - это задача программиста. Точней даже не формы, а данных, переданных в скрипт. А вот нарисовать ее юзеру - это работа дизайнера и верстальщика. Чисто в академических целях я написал класс для обработки форм, но его использование в повседневной работе мне кажется ненужным усложнением

 

[Observer]

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

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

-~{}~ 16.01.07 10:52:

+ в подобных системах дизайнерские изыски ни к чему, достаточно задать какие-то правила оформления (css), а дальше участие верстальщика ни к чему... Надеюсь, мысль понятна

 

[jonjonson]

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

Универсальный компонент - это нечто бесполезное.

 

[Phristen]

Класс конечно нужен. Но скорее для валидации, чем рисования, хотя это тоже.

Предлагаю свой способ У меня всего несколько классов (Form, абстрактный Field, и сабклассы Field: Input, TArea, Option), общим размером 12 кб. Валидация в-основном производится с помощью call_user_func_array().
Например, вызываем сл. методы объекта формы:

$form->addVldtnGroups("field1",0,"field2",0,"field10",0,"field3",1);
$form->addVldtnFuncs("function_a",0,"function_b",1);

В этом примере, методы создадут две валидационных группы: 1 и 0. Группа 0 (состоит из field1, field2, и field10), будет передана функции function_a, ну а группа 1 (состоит только из field3) - функции function_b.
Фактически вот так, но при использовании call_user_func_array:

function_a($field1, $field2, $field10);
function_b($field3);

По возвращаемым значениям (массив с двумя элементами: true/false чтобы знать корректны ли значения или комбинация значений группы, и сообщение от ошибке, в случае если некорректно) уже строится коррекционная форма. Плюс в том, что функцию можно написать любую, которая будет проверять самые нетривиальные задачи. Но в тоже время, 99% форм обойдутся двумя-тремя стандартными функциями, как то: проверка равенства двух или более полей, проверка уникальности значения в базе данных, и т.п.
Конечно, всему этому предшествует проверка элементарной правильности самого поля (проводится по regex'у, который является аттрибутом класса Field). Это отметает нужду в функциях типа isCorrectEmail и isCorrectURL

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

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

 

[jonjonson]

Phristen, а вы не думали, что никакой field нет?
А есть тэг

<input type="text" name="username" value="Вася" />

при отображении информации о пользователе для админа (предполагается правка).
И пара тэгов

<div class="userName">Вася</div>

при отображении информации для гостя?
Что первично в данном случае? Информация о пользователе или универсальный обработчик формы?