1

After much reading, I realized that Zend_Form can be divided into various representations, it fits well in view as the model.

Following the logic proposed by Matthew Weier O'Phinney, I got an idea to pass Doctrine [2] Entitie to the constructor of a class that extends Zend_Form, in the case, App_Form.

So in my entitie, I have a method for each form, following the pattern:

protected function _formFormName{}()

that Entitie extends the abstract class App_Form_Entitie, that have a method to retrieve the form:

final public function getForm($form = null)

and still have the methods isValid() and getMessage().

But many people prefer to leave the forms in separate files, see:

Where to place Zend_Forms, Controller? Model? Somewhere else?

I wonder which of these is the best way: Pass the entity to the constructor of the form as the first parameter, and the desired form such a, optional, second parameter, or get the form from the entity (as Matthew describes) and pass as first parameter the name of the desired form.

Any answer is welcome.

Here are two codes showing how the two examples would be, first, my proposal:

<?php
//My controller action
/* @var $em Doctrine\ORM\EntityManager */
$user = $em->find('MyNamespace\User', 1);
$loginForm = new App_Form($user, array('form'=> 'login'));
$this->view->loginForm = $loginForm;

//My view script
echo $this->loginForm;

And here the proposal of Matthew, in which the forms are in separate files:

<?php
//My controller action
/* @var $em Doctrine\ORM\EntityManager */
$user = $em->find('MyNamespace\User', 1);
$formLogin = $user->getForm('login'); //The entity creates a new instance of the class App_Form_Login and returns it.
$this->view->formLogin = $formLogin

//In my view...
echo $this->formLogin;
Community
  • 1
  • 1
jonathancardoso
  • 11,737
  • 7
  • 53
  • 72

1 Answers1

3

It doesn't seem right for the User entity to create App_Form objects. Your entities are idealized abstractions of your data which you reference in other parts of your application. This doesn't prevent you from having separate files for your Form types. I would go for something like your first option:

<?php
//My controller action
/* @var $em Doctrine\ORM\EntityManager */
$user = $em->find('MyNamespace\User', 1);
$loginForm = new App_Form_Login($user);
$this->view->loginForm = $loginForm;

//My view script
echo $this->loginForm
rojoca
  • 11,040
  • 4
  • 45
  • 46
  • Ok, so following the example, in my Entitie I have the protected method _formLogin() that return a array containing information about the form, in this case is a correct use, since I am not creating the object of the form itself, just have the data necessary to create it. Right? – jonathancardoso Apr 25 '11 at 21:46
  • The method would have to be public otherwise how could you access it? I'm not convinced you need such a method. In `App_Form_Login` you will have access to the `User` object which you can get/set values on. What else would you need from `User`? – rojoca Apr 25 '11 at 22:01
  • Why would you try and get the User entity to describe the form... isn't that what the form is for? – Cobby Apr 26 '11 at 03:22
  • I use something similar to rojoca's suggestion, I have a custom form class for each form. – Cobby Apr 26 '11 at 03:24
  • I have the class App_Form that extends Zend_Form and have the methods to get the form from the Entitie, so, I only use App_Form($entitie); – jonathancardoso Apr 26 '11 at 16:07
  • @Cobby I'm thinking of doing so, because in my view, the data to configure the form must be within the model layer of the MVC pattern, therefore, within the entity that will be used to manipulate the data from the form. Ah, English is not my primary language. x] – jonathancardoso Apr 26 '11 at 16:23
  • @Jonathan - Just create an App_Form_Login class that extends App_Form and do any configuration of the form in that class. Then your model layer (the User entity) only needs to do User logic not form logic. – rojoca Apr 26 '11 at 16:33
  • Thanks @rojoca, I'll use the way you said. – jonathancardoso Apr 29 '11 at 19:25