ZF2: Ansichtsskript von der Controller-Fabrik ändern

Question

In ZF2 habe ich 2 Helfer. Ein Helfer verfügt über ein Formular und einen Mapper für die Datenbankinteraktion. Ich übergebe diese Helfer mit einer Controller-Fabrik an den Controller. Der Controller behandelt Telefone und Adressen einer Partei, die entweder eine Person oder eine Organisation ist. Da es sich bei einer Partei um eine Person oder eine Organisation handelt, hat sie andere Daten. Die Controller-Factory übergibt also auch das Objekt: PersonObject oder OrganizationObject mit den partysspezifischen Daten an die Steuerung.

Die 2 Helfer sind für beide Partypen gleich. Aber im View-Skript möchte ich die Party-spezifischen Daten anzeigen, und hier ist mein Problem: Ich muss das View-Skript basierend auf dem Objekt ändern, das die Controller-Factory an den Controller übergibt. Ich dachte an zwei verschiedene Controller, aber es ist ein Overkill: Das View-Skript ist zu 90% das gleiche, abgesehen von den 10% Party-spezifischen Informationen, die von der Datenbank in das Party-Objekt kommen.

Wie ändert man das View-Skript von der Controller Factory? Wenn ich hier ändere, meine ich ein etwas anderes HTML-Layout mit den partyspezifischen Daten.

EDIT:

@Saeven vorgeschlagen, einige Code zu veröffentlichen. Im Moment habe ich beschlossen, ViewModel in der Controller-Fabrik zu erstellen, es entsprechend vorzubereiten und es in den Controller zu injizieren. Aber ich bin mir nicht sicher, ob es gut ist.

Der Helfer:

class ContactMechanismRegistrationViewHelper extends AbstractRegistrationViewHelper 
{ 
    public function __construct(
     FormInterface $form, 
     ContactMechanismMapperInterface $contactMechanismMapper 
    ) { 
     $this->form = $form; 
     $this->mapper = $contactMechanismMapper; 
    } 

    public function saveToDb() 
    { 
     $this->mapper->save(
      $this->form->get('contactMechanismFieldset')->getObject(), 
      $this->form->get('partyFieldset')->getObject() 
     ); 
    } 
} 

Die Helfer Fabrik:

class ContactMechanismRegistrationViewHelperFactory implements FactoryInterface, MutableCreationOptionsInterface 
{ 
    use MutableCreationOptionsTrait; 

    public function createService(ServiceLocatorInterface $serviceLocator) 
    { 
     $serviceManager = $serviceLocator->getServiceLocator(); 
     $formElementManager = $serviceManager->get('FormElementManager'); 

     if (in_array('phone', $this->creationOptions)) { 
      return new ContactMechanismRegistrationViewHelper(
       $formElementManager 
        ->get('Parties\Forms\Forms\ContactMechanisms\PhoneRegistrationForm'), 
       $serviceManager 
        ->get('Parties\Mappers\ContactMechanisms\PhoneMapper') 
      ); 
     } elseif (in_array('address', $this->creationOptions)) { 
      return new ContactMechanismRegistrationViewHelper(
       $formElementManager 
        ->get('Parties\Forms\Forms\ContactMechanisms\AddressRegistrationForm'), 
       $serviceManager 
        ->get('Parties\Mappers\ContactMechanisms\AddressMapper') 
      ); 
     } else { 
      throw new ServiceNotCreatedException('wrong option type specified'); 
     } 
    } 
} 

-Controller, der die Helfer verwendet:

class PartyDetailsController extends AbstractActionController 
{ 
    protected $phoneViewHelper; 
    protected $addressViewHelper; 
    protected $partyViewModel; 

    public function __construct(
     ContactMechanismRegistrationViewHelper $phoneViewHelper, 
     ContactMechanismRegistrationViewHelper $addressViewHelper, 
     ModelInterface $viewModel 
    ) 
    { 
     $this->phoneViewHelper = $phoneViewHelper; 
     $this->addressViewHelper = $addressViewHelper; 
     $this->viewModel = $viewModel; 
    } 

    public function indexAction() 
    { 
     $request = $this->getRequest(); 
     if ($request->isPost()) { 
      $viewHelperForFormSubmission = $this->getViewHelperForFormSubmission(
       $request->getPost('submitButton') 
      ); 
      $viewHelperForFormSubmission->getForm()->setData($request->getPost()); 
      $viewHelperForFormSubmission->getForm()->setIsSubmitted(true); 
      if ($viewHelperForFormSubmission->getForm()->isValid()) { 
       try { 
        $viewHelperForFormSubmission->saveToDb(); 
        $viewHelperForFormSubmission->getForm()->resetForm(); 
       } catch (\Exception $e) { 
        die($e->getMessage()); 
       } 
      } else { 
       $viewHelperForFormSubmission->getForm()->highlightInvalidElements(); 
      } 
     } 

     return $this->viewModel->setVariables([ 
      'phoneForm' => $this->phoneViewHelper->getForm(), 
      'addressForm' => $this->addressViewHelper->getForm(), 
     ]); 
    } 

    protected function getViewHelperForFormSubmission($submitValue) 
    { 
     if ($submitValue == 'phone') { 
      return $this->phoneViewHelper; 
     } elseif ($submitValue == 'address') { 
      return $this->addressViewHelper; 
     } else { 
      throw new \Exception('invalid submit argument'); 
     } 
    } 
} 

Answer 1

Nach erneuten Besuch meine Frage etwas weniger als ein Jahr später, beschlossen, meine Erfahrung zu teilen, vielleicht wäre es für jemanden von Nutzen.

Ich ging für verschiedene View-Skripte je nach Party-Typ. Was ich getan habe, ist, dass ich eine Fabrik erstellt habe, die eine Instanz eines Ansichtsmodells basierend auf der Art der Party erstellt. Es ist absolut in Ordnung, das Ansichtsmodell von der Steuerungsfabrik in die Steuerung zu injizieren. Wenn Sie eine Factory für das Ansichtsmodell erstellen, können Sie sie als Teil des Ansichtsmodells eines anderen Moduls wiederverwenden, indem Sie sie als untergeordnetes Element der Hauptversion ViewModel anhängen. Es ist manchmal sehr nützlich, wenn Sie moduleübergreifende Interaktion benötigen.

Ich fand heraus, dass die Idee von FormViewHelpers in meinem Fall nicht wirklich toll ist, weil es unnötige Komplexität und Hierarchie hinzufügt, weil alles, was mein FormViewHelpers tat, den Anruf direkt an den Dienst oder Mapper weitergab. Nur der Dienst mit eingefügter Abhängigkeit (oder Mapper) und Formular in den Controller waren für mich in Ordnung. FormViewHelpers, sind grundsätzlich keine schlechte Idee, wenn (!) Gibt es einige ganz Logik in gesetzt werden.

Ach, und übrigens, es ist ein großer Artikel von @yourcommonsense auf www.phpdelusions.net, die (im beschreibt) richtige Verwendung von Versuchs- und Fangblöcken. Es ist die wichtigste Nachricht, dass Sie try... catch... verwenden, wenn Sie ein bestimmtes Szenario für die Wiederherstellung des Fehlers haben. Ansonsten ist PHP selbst ziemlich fehleranfällig.

Das ist es. Viel Glück an jemanden, der in meinen vorherigen Schuhen ist. :-)