Я заметил, что многие (большинство?) Люди, работая с Zend Framework, добавляют декораторы и метки в сам класс Form.
class User_Form_Add extends Zend_Form
{
public function init()
{
parent::init();
$username = new Zend_Form_Element_Text('username');
$username->setLabel('Username:')
->setRequired(true)
->addFilter('StringTrim')
->addValidator('StringLength', $breakChainOnFailure = false, $options = array(1, 30))
->setDecorators(array(
'ViewHelper',
array('Description', array('tag' => 'p', 'class' => 'description')),
array('Label', array('requiredPrefix' => '<span class="asterisk">*</span> ', 'escape' => false)),
array('HtmlTag', array('tag' => 'p', 'class' => 'element'))
));
}
}
Но, конечно, это не хорошая практика? Я бы подумал, что декораторы и метки являются частью уровня представления в приложении MVC. Когда я смотрю на этот класс формы, он выглядит «разбитым» со всеми видами разметки, тегов и текста, которые должны быть в слое вида.
Этот подход означает, что если вам нужно поработать с разметкой вашей формы, вам нужно работать как с классом формы , так и с сценарием представления.
Мне не нравится эта концепция, и поэтому при рендеринге форм я разделяю формы и декораторы на подлинные сценарии представления. Я хочу, чтобы эти конфликтующие «проблемы» моего приложения были отделены друг от друга.
class User_Form_Add extends Zend_Form
{
public function init()
{
parent::init();
$username = new Zend_Form_Element_Text('username');
$username->setRequired(true)
->addFilter('StringTrim')
->addValidator('StringLength', $breakChainOnFailure = false, $options = array(1, 30));
}
}
// add.phtml:
$this->form->username->setLabel('Username:');
$this->form->username->setDecorators(array(
'ViewHelper',
array('Description', array('tag' => 'p', 'class' => 'description')),
array('Label', array('requiredPrefix' => '<span class="asterisk">*</span> ', 'escape' => false)),
array('HtmlTag', array('tag' => 'p', 'class' => 'element'))
));
echo $this->form->render();
Это оставляет класс формы чистым и вполне аналогичным модельному классу - так я воспринимаю класс формы; Он содержит фильтры, валидаторы и т. Д., Которые связаны с бизнес-логикой.
Если вы затем следуете этому подходу, это упрощает интеграцию ваших форм с вашими моделями, так что вы можете повторно использовать / получать доступ к валидаторам и фильтрам форм непосредственно из ваших моделей - без дополнительных затрат на создание декораторов и тому подобное. .
http://weierophinney.net/matthew/archives/200-Using-Zend_Form-in-Your-Models.html
Что касается сохранения ваших скриптов вида СУХИМ, чтобы вы не повторяли одни и те же метки и декораторы в нескольких представлениях (т. Е. Когда вам нужно визуализировать одну и ту же форму несколько раз, но в разных сценариях представления), я нахожу вас можно отделять повторно используемые части формы с помощью декоратора ViewScript, чтобы сохранить вещи СУХИМЫМИ.
РЕДАКТИРОВАТЬ : Кроме того, мы также можем переопределить декораторы по умолчанию на те, которые соответствуют нашему проекту, чтобы избежать необязательного объявления декораторов.
Итак, мой актуальный вопрос таков:
Почему никто не работает с такими формами? Какие недостатки вы видите для этого подхода?
Зачем создавать декораторы и метки форм в классе форм, если я могу так же легко добавить их в слой вида?
Я не понимаю, почему почти каждое использование Zend_Form, которое я вижу, включает добавление декораторов / меток в сам класс формы.