views:

70

answers:

4

Hi,

Zend_Form:: When should be form created in view and not in controller?

option 1 - form created in controller and passed to view (usually used)

controller:

$form=new MyForm();
$this->view->form=$form;

view:

echo $this->form;

option 2 - form created in view directly (looks better to me because form its subpart of view)

view:

$form=new MyForm();
echo $this->form;

Thanks

+1  A: 

I think the only first variant is correct, because Zend_Form is not presentation entity, but business logic entity. So it's wrong to try to instantiate it in the view. If you want simply display some form just mark up it directly in HTML - this will be much more easier for coder at least.

Ololo
i don't know efficient way to mark up form in HTML, because have to use validators
Yosef
+5  A: 

In short: newer in view.

You may eventually:

  • create view helper for complex tasks (and call the helper in view $this->getForm()),
  • or use Model::getForm()
  • or service::getForm() when you need cross-action forms.

Further explanation:

Because in the ideal case, views contain only HTML, to separate logic from presentation (MVC).

When using TDD, you write tests for logic, never for view scripts, which are only clothes for the variables.

Displaying the form, is not only the form itself, but also checking whether it was submitted or not, checking for validation errors, setting flash messenger variables and much more.

These are too complex tasks for putting them to view scripts.

As a good exercise on separating logic and presentation, I recommend you to take a look at PHPTAL template language, which is a nice alternative to native PHP as a template language used in ZF.

takeshin
Can you explain the reasons please
Yosef
+2  A: 

If a form appears in, say, the sidebar of a layout - like a "Subscribe to our mailing list" form - it seems reasonable to allow the view to create/render it on its own, though I'd probably do it within a view helper rather than have any new My_Form() calls in a view script. Why force every controller to deal with it?

As Padraic Brady notes in his online ZF book Surviving the Deep End: "Controllers Are Not The Data Police".

David Weinraub
but if the form add a comment to article / or add new product to catalog?is ok to put inside view script?
Yosef
The form will post its content somewhere - say controller=Book, action=addComment. As you note, that controller/action surely needs to deal with the form to validate, get the values, write the data, etc. In that case, having the form in the view script is not good enough. So you might want to have a service/factory class whose job it is to instantiate/remember that form. Then view scripts (for all pages) and any controller that needs the form can then access it via this factory class. The point of the factory class is to ensure that you are instantiating the form only a single time.
David Weinraub
How can you write TDD if form created inside a view, see takeshin answer please?
Yosef
I confess that I am not an expert at TDD. But in principle, it seems to me that it depends upon *what* you are going to test. If you want to test the functioning of the form, then you add unit-tests on the controller/action to which the form posts. If your intent is to confirm that the HTML markup for the form actually appears in the final rendered page, then you are closer to integration testing. In any case, the form will still be its own object - even if you use a factory to instantiate it - so it seems reasonable that you could write unit tests for the form itself as the SUT.
David Weinraub
A: 

Think about your team mates, are your designers( or graphical integrators ) programmers too? that approach will break down re-usability, and tasks separation.

P.M