Где находится Zend_Form в парадигме контроллера модели Model

Question

Zend Framework в основном предназначен для использования MVC. Одним из очень полезных компонентов является Zend_Form.

У меня есть немного проблем с поиском места Zend_Form. Является ли это частью представления, модели или контроллера и какие обязанности я должен ему дать.

Дело в том, что Zend_Form выполняет две функции: украшать и отображать форму и проверять ее. Первая - это задача реального вида, вторая - реальная модельная задача.

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

Другой вариант, заданный Matthew Weier O'Phinney, заключается в том, чтобы прикрепить форму к вашей модели и добавить дополнительные параметры просмотра в контроллер.

Итак, я сомневаюсь. Где в шаблоне MVC я должен разместить Zend_Form и как его использовать?

Редактировать Хорошие ответы пока, спасибо! Я буду награждать награду за час или два до истечения срока, поэтому, пожалуйста, дайте ответ, если у вас есть еще несколько мыслей!

Answer 1

Zend_Form можно просмотреть в разных точках. Он не может рассматриваться вообще как часть только одного слоя шаблона MVC.

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

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

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

public function newAction() 
{ 
    $form = $this->getForm(); 

    if($this->getRequest()->isPost()) 
    { 
     $formData = $this->_request->getPost(); 

     if($form->isValid($formData)) 
     { 
      $Model = $this->getModel(); 
      $id = $Model->insert($form->getValues()); 
     } 
    } 

    $this->view->form = $form; 
} 

Tie Формы для модели можно считать хорошим pratice, потому что, когда вы выполняете фильтрации и проверки действий вы на уровне модели.Так что, как Мэтью предложил:

class Model_DbTable_Users extends Zend_Db_Table 
{ 
    protected $_name = 'users'; 
    protected $_form; 

    public function getForm() 
    { 
     if(!$this->_form) 
      $this->_form = new Form_User(); 
     return $this->_form; 
    } 

    public function add($data) 
    { 
     $form = $this->getForm(); 
     if(!$form->isValid($data)) return false; 

     if($form->getValue('id')) 
     { 
      $id = (int) $form->getValue('id'); 
      $this->update($form->getValues(), 'id =' . $id); 
     } 
     else 
     { 
      $id = $this->insert($form->getValues()); 
     } 
     return $id; 
    } 
} 

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

Наконец, вы можете проанализировать свой контекст и подобрать один из этих двух подходов.

В настоящее время мой выбор состоит в том, чтобы связать формы с моделями. Выглядит хорошо! И для меня большой смысл.

Answer 2

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

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

Я думаю, идея О'Пинни также имеет большой смысл. Здесь он предпочитает рассматривать форму почти как компонент объекта домена, где он может добавить бизнес-логику. Это звучит просто прекрасно, если вы будете осторожны, чтобы сохранить всю логику вида для формы. Как он отмечает, речь идет о семантическом смысле. Не обязательно жесткое правило.

Answer 3

IMO, Zend_Form предназначен для ношения нескольких шляп. Это, по сути, мост между видом и моделью с гигантским опорным лучом от контроллера.

Вместо того, чтобы назначать форму модели, рассмотрите вопрос о назначении Модели (ей) форме.

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

Теперь в вашем слое формы создайте метод setupInputs, который будет проходить через массив моделей, чтобы захватить все входы. Если была только одна модель, добавьте входные данные в форму. Если было более одной модели, сделайте подформы.

Ваш контроллер инициирует форму и передает значения обратно в модель (см. Метод NewAction Keyne)