Zend_Form, QuickForm2, etc

MildMildMint

Новичок
Zend_Form, QuickForm2, etc

Плюсы:
1) Одна сущность
2) Более удобное отображение надписей валидаторов около элементов.
Минусы:
1) Кода не меньше по объему
2) Валидаторы в контрроллере не сложнее использовать, чем валидаторы элементов формы.
3) Не гибкое отображение.
4) Баги библиотек
5) Приходится выполнять работу верстальщика, кастомизируя внешний вид.
Сами смотрите: http://framework.zend.com/manual/ru/zend.form.quickstart.html

Количество минусов больше, чем плюсов. Обоснуйте положительный опыт использования подобных библиотек.
У меня не получалось получить с них пользу, только одни неприятности(время на чтение документации, время на борьбу со внутренностями библиотек, время на переписывание)
 

AmdY

Пью пиво
Команда форума
MildMildMint
о плюсах - любая форма делается за пять минут методом копипаста, причём уже с валидацией и без xss.

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

fixxxer

К.О.
Партнер клуба
Я делаю примерно так:
PHP:
$Form
->cloneFrom($Model->attributes()) // можно клонировать из модели
->addFields(array(
    'foo' => new Field_Scalar, // никаких input или checkbox - это view логика
    'bar' => new Field_Enum(array $values), // а будет это select или набор radio - вопрос верстальщика
    'test' => null, // можно и просто значение
))->addRules(array(
   'foo' => array(new Rule_IsEmail)
))
->fetchFrom($_POST)
->validate()
....
$Form->renderInto($this->View->Form)
В шаблоне же хелперы вида
PHP:
{{ form.begin(Form) }}
{{ form.input(Form.foo) }}
{{ form.select(Form.bar) }}
{{ form.end() }}
Как минимум проблемы номер 3 и 5 это решает
 

Sad Spirit

мизантроп (Старожил PHPClub)
Команда форума
Автор оригинала: MildMildMint
1) Кода не меньше по объему
Ммм... а в чём меряется объём кода?

2) Валидаторы в контрроллере не сложнее использовать, чем валидаторы элементов формы.
Естественно, если уже есть готовые валидаторы, то всё равно где их использовать. А если их пока нет?

3) Не гибкое отображение.
В админке сайта, где наибольшая концентрация форм, гибкость отображения нужна не слишком. Можно на весь проект один шаблон завести.

4) Баги библиотек
Библиотека, которой пользуются тыщи людей, будет содержать меньше багов, чем домашние разработки.

5) Приходится выполнять работу верстальщика, кастомизируя внешний вид.
Сами смотрите: http://framework.zend.com/manual/ru/zend.form.quickstart.html
За Zend_Form не скажу, но в QF2 можно верстальщика в "шаблоне" заставить писать заклинания наподобие
PHP:
echo $form->getElementById('foo')->mergeAttributes('class="bar baz" style="width: 300px"');
ну или сделать для этого конструкции попроще.
 

MildMildMint

Новичок
Ммм... а в чём меряется объём кода?
Во времени его написания. И все этапы присутствуют в обоих способах.

А если их пока нет?
Не правда. Common-валидаторы есть.
В любом случае технически валидатор для элемента формы не отличается от валидатора в другом месте.

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

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

echo $form->getElementById('foo')->mergeAttributes('class="bar baz" style="width: 300px"');
И это дополнительный этап взаимодействия с верстальщиком.
 

Groove

Новичок
Re: Zend_Form, QuickForm2, etc

Автор оригинала: MildMildMint
Плюсы:
1) Одна сущность
2) Более удобное отображение надписей валидаторов около элементов.
Минусы:
1) Кода не меньше по объему
2) Валидаторы в контрроллере не сложнее использовать, чем валидаторы элементов формы.
3) Не гибкое отображение.
4) Баги библиотек
5) Приходится выполнять работу верстальщика, кастомизируя внешний вид.
Сами смотрите: http://framework.zend.com/manual/ru/zend.form.quickstart.html

Количество минусов больше, чем плюсов. Обоснуйте положительный опыт использования подобных библиотек.
У меня не получалось получить с них пользу, только одни неприятности(время на чтение документации, время на борьбу со внутренностями библиотек, время на переписывание)
Думаю в этом вопросе решений не так много: либо делать каждый раз руками уникальные по функциональности и дизайну формы, либо использовать какой то генератор форм, покрывающий большинство потребностей, в это случае снова вилка: либо писать свой с нуля с блекджэком и т.д., либо использовать наиболее подходящий с доработками.
Я пошел именно этим путем и не жалею об этом (чуть-чуть доработал QuickForm2 для своих нужд).

А кода, кстати, в разы меньше, если потратить немного времени на создание типовых элементов, что в Zend_Form, что в QF(x.x).
Пример с использованием нестандартных виджетов типа DateTimePicker: http://jquickform.ru/?page=dt_datepicker
PHP:
    $form = new jQuickForm('simple');
        $form ->insertDatePicker('datepicker')
        ->setLabel('Выбор даты (формат yy-mm-dd)')
        ->setComment('Кликните на поле вызова datepicker')
        ->setExample(date('Y-m-d'));
Чтобы сделать тоже самое БЕЗ QuickForm как минимум нужно было бы руками прописывать подключение jQueryUI, onload, etc
Или другой пример, использование SWFUpload: http://jquickform.ru/?page=files_file_multi
PHP:
$form = new jQuickForm('simple');
$form->insertMultiUpload('file','/cms/upload/index.php');
Тоже самое: посмотрите сколько всего пришлось бы подключить и инициализировать, чтобы заработало, а тут всего одна строчка.

Удобно использовать, когда есть более менее устоявшиеся в проекте способы отображения формы (имеется в виду расположение внутри конкретного элемента формы его частей: метки, подписи, самого элемента).
Практически не приходится лезть руками в HTML, а также в большинстве случаев вообще касаться шаблонов, многие вещи в принципе можно решить при помощи CSS, поэтому возможен быстрый старт.
Это конечно же касается в основном простых форм, например в админке, где важна функциональность, а не уникальность, но если же у вас какая то специфичная верстка - просто делаете шаблон для элемента или вообще всей формы http://jquickform.ru/?page=examples_odnoklassniki

Ну и напоследок, хотелось бы цитату вспомнить, она весьма в тему будет:
# Paul Lomax : "1. Используй то, что есть."
# Paul Lomax : "2. Осознай, что это полный отстой."
# Paul Lomax : "3. Напиши свое."
# Paul Lomax : "4. Подожди, пока кто-то выпустит меньший отстой."
# Paul Lomax : "5. Забрось свое. Используй чужое"
 

MildMildMint

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


Практически не приходится лезть руками в HTML
Я вижу в этом только минусы: программисту все равно, а вот верстальщику не в HTML никак.

Кстати да. Что делать верстальщику, если надо сверстать форму? Отдавать верстку программисту, чтобы он все это прописывал в форме?
А если надо изменить ее - снова тревожить программиста?

А кода, кстати, в разы меньше, если потратить немного времени на создание типовых элементов, что в Zend_Form, что в QF(x.x).
С чего бы?
Чем addValidator() отличается от if (a > 4) или от if(Validate::is($e, 'Email'))?
Верстку то верстальщик все равно делает.
 

AmdY

Пью пиво
Команда форума
MildMildMint
а ты напиши полный пример и увидишь:
1. в коде проверка пришла ли форма
2. проверка значений и формирование массива с офибками
3. если массив не пуст, то сново показывать форму
4. если валидация не прошла показать форму с заполенными данными
5. в шаблоне вывод ошибок возле каждого поля.
 

Sad Spirit

мизантроп (Старожил PHPClub)
Команда форума
Автор оригинала: MildMildMint
Кстати да. Что делать верстальщику, если надо сверстать форму? Отдавать верстку программисту, чтобы он все это прописывал в форме?
А если надо изменить ее - снова тревожить программиста?
Осторожно поинтересуюсь: а без использования библиотек построения форм верстальщик, конечно же, сможет сделать всё сам?
 

MildMildMint

Новичок
Пункты 1-4 количество кода одинаково.
Пункт 5 в формогенераторах проще.
Но есть и лишний пункт: отображение.
И еще одно лишнее звено программист-верстальщик.

-~{}~ 26.10.10 13:55:

Осторожно поинтересуюсь: а без использования библиотек построения форм верстальщик, конечно же, сможет сделать всё сам?
Что именно?
 

Groove

Новичок
Автор оригинала: MildMildMint
Кстати да. Что делать верстальщику, если надо сверстать форму? Отдавать верстку программисту, чтобы он все это прописывал в форме?
А если надо изменить ее - снова тревожить программиста?
Я уже говорил, что в некоторых случаях достаточно модифицировать файл стилей, а не верстать _каждый_ раз с нуля форму, пример: http://jquickform.ru/?page=custom_view_css
Другое дело, что не везде одинаково принято КТО должен вносить изменения: верстальщик - в, возможно активный, шаблон формы, или программист - в код генератора форм.
Тут дело привычки, мне например одного взгляда на верстку формы бывает достаточно, чтобы уже представить где и как нужно поправить шаблон для элемента формы

Опять же вспомните про http://ru.wikipedia.org/wiki/CSRF - генератор форм может это делать прозрачно для прикладного программиста.

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

Причем, если мне не будет хватать какой то гибкости при помощи стандартных виджетов, я могу в форму хоть сиськи добавить http://jquickform.ru/?page=elements_static при помощи элемента Static.
 

MildMildMint

Новичок
Я уже говорил, что в некоторых случаях достаточно модифицировать файл стилей, а не верстать _каждый_ раз с нуля форму, пример: http://jquickform.ru/?page=custom_view_css
Эм? Я не понял, где разница в количестве кода.
Для программиста в сверстанной форме надо прикрепить лишь нужные имена(либо верстальщик дорабатывает форму программиста, подгоняя ее под дизайн).

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

Другое дело, что не везде одинаково принято КТО должен вносить изменения: верстальщик - в, возможно активный, шаблон формы, или программист - в код генератора форм.
Вы хотели сказать "верстальщик - в, возможно активный, шаблон формы, или верстальщик и программист - в код генератора форм"?

Опять же вспомните про http://ru.wikipedia.org/wiki/CSRF - генератор форм может это делать прозрачно для прикладного программиста.
Создал отдельную тему. http://phpclub.ru/talk/showthread.php?threadid=120903

Причем, если мне не будет хватать какой то гибкости при помощи стандартных виджетов, я могу в форму хоть сиськи добавить http://jquickform.ru/?page=elements_static при помощи элемента Static.
Можно и хелпером сделать с теми же усилиями.
 

Sad Spirit

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

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