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

[Bermuda]

Автор оригинала: Фанат
не вижу я там никакого шаблона собственно полей формы.

На время забудем про поля формы и представим элементы формы как объекты классов.

Во view мы определяем какого класс должен быть элемент формы

$this->txtValue1 = new QTextBox($this);

А в шаблоне только отображаем этот элемент

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

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

$this->txtValue1 = new QTextBox($this);

на

$this->txtValue1 = new QFileControl($this);

1. Шаблон остается неизменным, нам не приходится переписывать ни единой строчки.
2. Автоматически меняются методы валидации как на стороне клиента, так и на стороне сервера, что также снимает головную боль.

Конечно, ручную проверку никто не отменял, но подобным формам можно доверить тупую валидацию формата данных. Если ожидается номер счета в банке, то он должен быть введен в определенном формате (минимальный/максимальный размер, контрольная сумма, только цифры и т. д.). Благодаря повторному использованию классов элементов формы не приходится каждый раз ломать голову над валидацией формата данных. Подобная валидация уменьшает количество мусора летящего в приложение, также разгружает часть функционала. Если я ожидаю получить email-адрес, то вместо двух проверок -- валидность формата и существование адреса, мне остается сделать только одну -- последнюю.

Я уже слышу крики из зала "дизайн формы это не задача программиста" и "дизайнер теряет контроль над дизайном формы".
Абсолютно верно. Вот здесь показано каким образом дизайнер может контролировать дизайн формы.

Обратите внимание, что код View остался практически неизменным относительно прошлого примера. Внешний вид элементов формы задан в шаблоне. Более того, теоретически, подобный подход позволяет для разных клиентов выводить разные формы. Например в зависимости от браузера или в зависимости от прав пользователя.

 

[Quessir]

Фанат

А я как раз предпочитаю работать с конструктором форм. Это уменьшает кол-во кода. Да и работать с ним легче.

 

[Фанат]

Bermuda
Ясно.
Данная реализация ничем не отличается от других классов для рисования форм. Спасибо за участие.

 

[Bermuda]

Фанат
Вообще-то отличается. Код view отделен от шаблона, на чем был сделан акцент в начале темы. Но самое привлекательное это "stateful, event-driven architecture". event-driven - на любые манипуляции с объектами формы можно повесить свой обработчкик, как на стороне сервера, так и на стороне клиента.
Что они понимают под stateful можно посмотреть здесь и здесь

-~{}~ 16.01.07 11:54:

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

Это называется подмена понятий.

С абстрактной точки зрения тег <a> отличается от тега <input> тем что,
тэг <a> -- принадлежит множеству элементов web-страницы
тэг <input> -- принадлежит множеству элементов формы (форма в свою очередь элемент web-страницы)

Тэг <input> вне формы не имеет смысла (кроме разве что извращенных форм навигации).

Я правильно понял, что вопрос бы по рисованию форм, но не по рисованию страниц? Тэг <a> не относится к множеству элементов формы. Более того, любой тэг <a> находящийся внутри формы всегда можно вынести вне формы, а тэг <input> нельзя.

 

[С.]

Фанат, я полагаю, что главное различие между <a> и <input> в данном случае в том, что в <a> только одна компонента подменяется и это красиво делается шаблоном:

<a href="<?=$url?>">

В <input> их как минимум две: name и value. А еще могут быть checked, readonly и т.п. Однозначно, что использовать отдельную шаблонную переменную на каждую компоненту слишком неэффективно:

<input type=text name="<?=field_name?>" value="<?=field_value?>">

Поэтому и возникает естественное желание заграбастать весь тег в код.

Есть один промежуточный, но немного "скользкий" вариант:

<input <?=field_data?> size=10 style="background-color:...">

Формально в код попали элементы HTML, но с другой строны они на дизайн никак не влияют. Вроде как овцы целы.

 

[AmdY]

В одном из проектов довелось делать форму с 150 полями, причём заказчик несколько раз менял мнение о типе полей и именах. Другого выхода, кроме как автоматическая генерация формы на основе поле из БД не было, плюс генерация закладок.

 

[tf]

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

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

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

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

Ваше мнение?

мое мнение нужен, когда постоянно делаеш что-то однотипное большое желение этого больше не делать,
обработка данных, отображение.
я не знаю даже уже сколько мне постоянно пришлось бы писать кода на типичную обработку данных - upload, resize картинок
к тому же тут упоминали об ajax, по опыту - в админку было не оч сложно добавит поддержку - заставить генерить js код для отрисовки новых обработанных данных (просто дабавил функцию к класс и получил данных) и просто передавать его на страницу, форма показывается как надо - с мин моего участие с возможным мин допущенных мною ошибок
т.е. уменьшается возможность мною чтонибуть пропустить
минус - по себе - это чудо в 54кб в данный момент надо как-то упрощать или сделать small версию для отображения на самом сайте - большинство функций просто не надо


по поводу отображения, наверное соглашусь с С.

В <input> их как минимум две: name и value. А еще могут быть checked, readonly и т.п. Однозначно, что использовать отдельную шаблонную переменную на каждую компоненту слишком неэффективно:

как-то надо генерить html тег - это не только input но и select (который еще сложнее)
т.е. использовать для этого класс View

Автор оригинала: Bermuda
Угу, одна форма на страницу, тоже не нравится. Но в большинстве случаев хватает одной формы, также уже нашлось решение для случаев когда нужно несколько форм.

незнаю, мне например нехватает особенно когда редактирование списков данных реализую (а кто его знает сколько тогда форм на странице выходит), благо все это нормально обходится созданием массивов входящих данных form1[input]

 

[Sad Spirit]

Я смотрю тут тема вырождается в хвалебные песни куликов своим болотам. И обсуждение абстрактных сферических форм и классов в вакууме.

Разделение кода / шаблона / модели / контроллера / преставления дело, безусловно, полезное. Только вот сами теги HTML для форм мешают всё в одну кучу, например:

<input type="text" name="name" size="10" maxlength="20" value="foo" />

здесь атрибут size задаёт представление (размер поля ввода), maxlength --- правило проверки (относящееся к ведению контроллера), а value --- значение, поступившее либо из модели, либо от пользователя. Заметьте, это ещё простой вариант, радиокнопки и <select>'ы гораздо веселее. Добавим сюда ещё Javascript, вопрос генерации которого (или у вас его верстальщик пишет, ага?) я упомянул в своём первом посте и который постарались "незаметно" слить:

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

Вот от этого обстоятельства давайте и начнём плясать, упомянув для полноты картины XForms, где данные, проверки и представление разделены. Но, учитывая отсутствие встроенной поддержки XForms в IE 7, на этом упоминании и остановимся.

Потом упомянем, что вопрос хранения данных о форме абсолютно ортогонален вопросу того, как по этим данным форму генерировать. Любой хитровы@#анный XML можно трансформировать в PHP код, работающий с произвольным хитровы@#анным классом генерации форм. У меня самого написан простенький построитель форм, позволяющий в бэк-офисе собрать форму обратной связи из произвольных полей, который хранит данные о форме в базе и в конечном итоге использует QuickForm для вывода и проверки формы.

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

Теперь перейдём от абстрактных сферических форм в вакууме к конкретным, каковых можно насчитать 2 вида:
1) Формы бэк-офиса (CMS)
2) Формы морды сайта

Если с первыми можно обойтись одним шаблоном (я собственно сам так и делаю), в коем фактически задан цикл вывода полей, привлекая верстальщика 1 раз в самом начале для создания оного, то со вторыми это не всегда прокатывает. То что тут подбрасывали в виде QForm ничем не лучше использования "статических" Renderer'ов в QuickForm, потому что как верно было отмечено, верстальщику одинаково неудобно рисовать подстановку типа {$form.pass.html} или писать <?php $this->txtValue1->Render(); ?> не видя что получится в результате. Идеальный вариант --- верстальщик сношает чистый HTML, в коем теги форм содержат какие-то левые данные, а потом по нему генерируется файл, куда уже выводятся сгенерированные теги HTML.

Дальше тут предлагают валидацию полностью разнести с генерацией. Ага, конечно, вот например форма

<input type="radio" name="answer" value="yes" />Да<br />
<input type="radio" name="answer" value="no" />Нет<br />
<input type="radio" name="answer" value="maybe" checked="checked" />Х.з.<br />

После "отправки формы" в поле answer массива $_POST имеем слово "Х$й". Ну, вы собираетесь это слово проверять в отрыве от формы, не учитывая тот факт, что оно по смыслу из формы придти не могло? Или будем хранить массив возможных значений в паре мест (в шаблоне и модели), чтобы, такскть, облегчить модификацию программы и снизить вероятность ошибки?

 

[tf]

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

ну и ты тоже о своем болоте

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

помоему об этом еще никто не говорил что надо держать данные в двух местах, или я что-то пропустил?

 

[Sad Spirit]

Автор оригинала: tf
помоему об этом еще никто не говорил что надо держать данные в двух местах, или я что-то пропустил?

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

 

[Bermuda]

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

А зачем все уперлись рогом в HTML? Как от базы данных, так мы абстрагироваться умеем, как от HTML, так нет. И что вы привязались к этим инпутам.
Я уже намекал на то, что элементы формы можно рассматривать как классы, со всемы отсюда вытекающими. Как они будут рендериться в форме, это уже дело предпоследнее.

Автор оригинала: tf
незнаю, мне например нехватает

Ну хорошо, у тебя на странице туева хуча форм, но сабмитить ты ведь собираешься только одну, а не все вместе?

 

[asm]

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

В проектах где количество форм сводится к форме регистрации, да еще не более десятка простейших не вижу необходимости в таком классе.

 

[crocodile2u]

С валидацией я лично в последнее время поступаю просто: форма сабмитится с пом. аякса (если это не XForms, конечно ). Сервер проверяет данные и выдает клиентскому скрипту назад ошибки, буде таковые найдутся. Правила валидации и тексты ошибок хранятся/формируются в одном месте - на сервере.

 

[tf]

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

Автор оригинала: Bermuda
Ну хорошо, у тебя на странице туева хуча форм, но сабмитить ты ведь собираешься только одну, а не все вместе?

когда как, субмит может быть один или несколько

 

[alexeyco]

Я занялся данным вопросом... Обоснованно это как раз такими мыслями:
1 - единообразие форм
2 - сокращение кода
3 - универсализация их валидации (задаем типы проверок и сообщения в случае ошибки) и после перезагрузки получаем ЗАПОЛНЕННУЮ форму с замечаниями по каждому неверно заполненному полю. Или получаем действие на основе данных, если все верно. Это действительно имеет ряд плюсов.

Класс весит около 9 кб... Работает в связке с шаблонизатором из phpBB (не надо по этому поводу, бо если кому надо, то легко переделать под любое другое творение, там дизайна мало).

Что хочу сделать.
1 - Валидацию (ajax)
2 - Динамически генерирующиеся поля форм (ajax)

Кто хочет поучаствовать или если у кого есть готовые наработки - буду очень рад.

 

[tf]

1 - Валидацию (ajax)
2 - Динамически генерирующиеся поля форм (ajax)

сначало объясни что ты имееш ввиду под валидацией ajax
ajax - не делает валидацию
в нашем случае это связка php и JavaScript
валидацию ты делаеш на на php
ajax помогает не перегружать страницу

Кто хочет поучаствовать или если у кого есть готовые наработки - буду очень рад.

ну есть решение (только один момент не устраивает) на 52 kb

 

[Фанат]

ребят, давайте в своей теме
участвуйте, валидируйте, разрабатывайте

 

[WP]

Я вынес задачу рисования форм в шаблонизатор, так чтобы код шаблон был при этом читабельным (засчет тегов {input} и т.д.), а валидацию заполнения не нужно формализовывать, достаточно if'ов которые заполняют массив ошибок.
А дизайнеру удобно и программисту легко. А подход Qcodo считаю неправильным, т.к. не надо мешать формы и PHP. Ведь PHP не знает что такое форма, и знать не должен.

 

[Bermuda]

подход Qcodo считаю неправильным, т.к. не надо мешать формы и PHP.

И где ты там мешанину высмотрел?

 

[WP]

> protected function btnCalculate_Click
Вот здесь.