Формы в Zend Framework

передать то хакер сможет, а вот валидатор как раз при проверке и заругается что пришло слишком длинное поле, и данные в БД не попадут…

>При этом если вы ее не будете фильтровать в обработчике, то рискуете получить много проблем.
так а Zend_Form это и есть обработчик в данном случае, валидация то отрабатывает на стороне сервера

Валидаторы/фильтры синтаксически сократить нельзя, но в целом создание формы можно писать короче, без явного применения оператора new

        $form->addElements(array(
            array ('text', 'email', array (
                'label'         =>  'E-mail',
                'required'      =>  false,
                'filters'       =>  array(
                    'StringTrim'
                ),    
                'validators'    =>  array(
                    'EmailAddress'
                )
            ))
        ));

Как минимум потому, что Элемент формы != Инпут.
В общем случае элементом формы может быть любая конструкция HTML. (Например: 3 селекта для выбора даты, и hidden input для придуманных дизайнерами чекбоксов).
Но есть декоратор error. Встроенная его версия — добавляет список ошибок рядом с элементом формы. Ничто не мешет заменить его на свой декоратор, который помимо этого будет оборачивать сам элемент формы в с каким-либо классом

Мы в таком случае переопределяли колбэки декораторов элементов формы на свои собственные. А какие-то динамические вещи вешали на jQuery.

А вы случайно не мне ответили? Если мне, то я всегда считал, что значение аттрибута id должно быть всегда уникально, а имя может повторяться.

формы — модели, они занимаются валидацией и обработкой данных пришедших извне, используют свой вью для рендера, что плохого? без них вы всеравно сделаете модель для валидации данных, и в шаблон напихаете HTML кода… выйдет тот же результат, но не такой гибкий

1. не совсем понятно, все что вы указали, присутствует в стандартных декораторах, для required, это в параметрах:
'escape' => false,
'requiredSuffix' => '*:',
'optionalSuffix' => ':'
Description — для описания, это совсем просто, как и добавить label

2. для этого есть 2 варианта, прерывать chain валидаторов или нет, true/false. Можно написать кастомный валидатор, который выводит ошибки в одну кучу, а не под каждым элементом

3. для этого вы можете переписать метод isValid вашей формы. Например:

class Form_Login extends App_Form
{

public function init()
{
//конструктор формы
}

public function isValid($data)
{
//проверка данных на подлинность
}
}

4. на сколько больше или меньше кода, это не показатель, в результате хардкодить формы получается дольше, но прошу, не начинайте холивар, т.к формы у разных проектов разные, + вам встречный вопрос, как вы напишите unit-test'ы для хтмл форм?;)

я делал элемент group в который можно было влаживать другие элементы, выглядело примерно так:
$elemLabel = new Label(...)
$elemSpan = new Span(...)
… тут куча нужных элементов
$elemGroup = new Group(...)
$elemGroup->addElement($elemLabel)->addElement($elemSpan)->etc…
так есть возможность дать каждому элементу свой декоратор + группе декоратор + группы можно группировать
Вывод результата тоже изменял, у нас результат появлялся над формой в своем оформлении
стандартная проверка — декоратор поумолчанию который нужно убрать, у нас был свой декоратор для формы который менял вид самой формы + выносил ошибки наружу (это если вы имеете ввиду показ ошибок) вообще валидация идет с помошью валидаторов, пишете свой валидатор, добавляете и все работает как вам нужно (это если вы имеете ввиду проверку ошибок)

4 был замечательный мультик, и там звучала фраза: «лучше день потерять, но потом за один час долететь»… так и получается, один раз посидеть долго, но потом все будет намного проще

блин, сколько раз я говорил себе фразу "… разгребусь с делами, и..!"

а форма и не знает об html она знает о декораторе, что он там делает ей уже плевать, она отдает данные, и получает завуалированный результат, будь то html, xml, JSON, etc

вообще, все зависит кто и как его использует, Zend_Form для полноты всегда нужно «подпиливать» под свой проект, редко можно увидеть крупные, серьезные проекты (я не говорю о всяких там личных страничках, да и интернет магазинах), которые работают со стандартными не затюниным Zend_Form, в статье действительно немного подход, скажем так, для обычного начала.

К автору появляется вопрос:

Вы перевели статью просто из личного интереса, или вы всетаки напрямую работали с Zend_Form'ами и вам эта статья помогла в них освоиться?

формы можно наследовать, с ней оч удобно работать как с объектом =)

Если несложно можно прислать пример формы на Zend'e мне в личку? В ответ, после разбора кода и написания кода по аналогии для cвоих проектов — обязуюсь написать статью в хабр ;)

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

К сожалению производительность — плата за гибкость

Сборка всего Зенда в один файл и eAccelerator/APC спасут отца русской демократии :)

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

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

p.s. быть может framework.zend.com/wiki/display/ZFPROP/Zend_Form_Generator вызреет когда-нибудь

Кто мешает написать наследника от Zend_Form и прописать в него то, что вы часто используете?
Я так и делаю.
Модели привязать к форме тоже проблем не вижу, если это необходимо.
Zend_Form и Zend_Form_Element — это базовые классы. Расширяйте их как угодно, все же объектно.
У меня, например, есть элемент с автодополнением, выбора даты, вкладок, визуального редактора,… это очень удобно. Один раз пишешь, потом просто используешь.

По производительности — фникто не запрещает формы кэшировать — подключите к ней Zend_Cache — хоть на уровне объектов, хоть на уровне HTML.

По декораторам — они реально удобны для быстрого парсинга. Делаете несколько вариантов и используете в зависимости от требований. В основном, управляя структурой. У меня, например, по типам полей добавляются классы контейнерам в декораторах. А все оформление делается в CSS.
Нарушения MVC не вижу, считаю декораторы частью View.
Если хочется чистого разделения — кто мешает? Отключаете все декораторы, форму рендерите вручную, с помощью view, причем, как угодно.

Zend_Form очень гибок и функционален, впрочем, как и весь Zend Framework.

Управляйте. Назначайте форме рендер через view и парсите — хоть через цикл, хоть вручную поэлементно.