Wir als Mensch wissen sofort, dass firstName und lastName ein Text sind. Auch beim Alter sind wir uns einig, dass es sich um ein Zahlenfeld handelt. Der Request, der bei Extbase jedoch ankommt schaut folgendermaßen aus:

array(3 items)
   action => 'create' (6 chars)
   controller => 'PropertyMapper' (14 chars)
   person => array(3 items)
      firstName => 'Stefan' (6 chars)
      lastName => 'Frömken' (8 chars)
      age => '35' (2 chars)

Hier kann man sehr schon sehen, dass die Transfermethoden nur Text und Arrays interpretieren können.

und hier die Debugausgabe unseres Models:

StefanFroemken\Sfpm2\Domain\Model\Personprototypetransient entity
   firstName => 'Stefan' (6 chars)
   lastName => 'Frömken' (8 chars)
   age => 35 (integer)
   uid => NULL
   _localizedUid => NULL
   _languageUid => NULL
   _versionedUid => NULL
   pid => NULL

Nur durch die Angabe der Datentypen in unseren Domainmodellen, weiß der Property Mapper in welches Format die ankommenden Daten zu konvertieren sind. Sehr schön zu sehen an dem Beispiel mit der Eigenschaft “age”, die hier bereits nach integer konvertiert wurde.

Ich greife hier auf alle Personenfelder zu und lade mir die Property Mapper Konfiguration. Hier nun gibt es eine Methode, mit der ich den Untereigenschaften von “Person” einen anderen Datentypen zuweisen kann. Für das Alter setze ich den Datentyp auf “string”. In unserer Debugausgabe erscheint nun:

StefanFroemken\Sfpm2\Domain\Model\Personprototypetransient entity
   firstName => 'Stefan' (6 chars)
   lastName => 'Frömken' (8 chars)
   age => '35' (2 chars)
   uid => NULL
   _localizedUid => NULL
   _languageUid => NULL
   _versionedUid => NULL
   pid => NULL

Da dieser Wert aber nicht in der Datenbank gespeichert werden darf, fügen wir diese Eigenschaft auch nicht in unser Domainmodel ein. Wenn wir jetzt speichern erhalten wir eine Exception:

#1297759968: Exception while property mapping at property path “”:Property “gender” was not found in target object of type “StefanFroemken\Sfpm2\Domain\Model\Person”.

Diese Exception zwingt uns nun förmlich eine Eigenschaft im Domainmodel anzulegen, aber das wollen wir nicht. Somit behelfen wir uns wieder mit der Property Mapper Konfiguration:

Auf diese Weise wird die Eigenschaft “creaditCard” nun nicht in das Domainmodel gemapped und wird somit auch nicht gespeichert. In die Methode skipProperties() könnt Ihr auch mehrere Eigenschaften komma-separiert angeben. Für den weiteren Prozess, wie die Überprüfung der Kreditkartendaten könnt Ihr im Controller immer noch mit Hilfe dieser Zeilen zugreifen:

Das Ergebnis im Frontend schaut auf den ersten Blick zwar OK aus und es ist auch eine Mehrfachauswahl möglich, aber zum Server wird immer nur die letzte Zutat geschickt. Wenn also Salami und Pilze markiert wurde, wird die Variable Pizza nur mit “Pilze” befüllt. Der Wert “Salami” wird schlicht vergessen. Was im Template fehlt sind diese eckigen Klammern [], um dem Formularfeld mitzuteilen, dass es mehrere Daten als Array aufnehmen kann. Also probieren wir den nächsten Schritt:

Anstatt besser, wird es jetzt sogar noch schlimmer. Im HTML-Quelltext steht nun:

tx_sfpm2_pm2[person][pizza[]]

Erst mit TYPO3 7.0 wird ein neuer Parameter “multiple” für Checkboxen eingeführt, der dann korrektes HTML erzeugt. Aber bis dahin müssen solche Implementationen selbst gebaut werden:

Als Dank für eine fehlende Unterstützung seitens Fluid erhalten wir bei Speicherung eine Exception:

#1297759968: Exception while property mapping at property path “”:It is not allowed to map property “pizza”. You need to use $propertyMappingConfiguration->allowProperties(‘pizza’) to enable mapping of this property.

Hintergrund

Sobald der ViewHelper f:form verwendet wird, unterhält sich dieser mit jedem weiteren f:form.* ViewHelper. Wird ein weiteres Formularfeld hinzugefügt, wird auch ein verstecktes Feld mit dem Namen __trustedProperies entsprechend erweitert:

<input name="tx_sfpm2_pm2[__trustedProperties]" value="a:1:{s:6:"person";a:4:{s:9:"firstName";i:1;s:8:"lastName";i:1;s:3:"age";i:1;s:10:"creditCard";i:1;}}3cc0974de797a6278e67448a0b4cefbcc776e6ff" type="hidden">

Da wir in dem Beispiel oben aber nicht mehr mit einem f:form.* ViewHelper arbeiten, geht diese Verbindung verloren und dieses versteckte Feld, wird um unser neues Feld nicht erweitert. Nach dem Absenden des Formulars wird innerhalb von Extbase der Wert diesen versteckten Feldes abgearbeitet und jedes dort aufgeführte Formularfeld wird einer Liste der erlaubten Felder hinzugefügt, die auf die Eigenschaften des Domainmodels gemapped werden dürfen.

Das was Extbase Dank diesem versteckten Feld automatisch für uns abnimmt, müssen wir nun für unser selbst kreiertes Formularfeld nachholen:

Nach der Speicherung erhalten wir noch die Exception bzgl. der vergessenen Eigenschaft in unserem Domainmodel:

#1297759968: Exception while property mapping at property path “”:Property “pizza” was not found in target object of type “StefanFroemken\Sfpm2\Domain\Model\Person”.

Also fügen wir die Eigenschaft mit Getter und Setter im Domainmodel hinzu:

Nach der Speicherung kommt gleich die nächste Exception:

#1297759968: Exception while property mapping at property path “pizza”:No converter found which can be used to convert from “array” to “string”.

Da haben wir den Salat. Wir erhalten die Daten für unsere Pizza als Array. Ein Array lässt sich aber nicht so 1zu1 in der Datenbank speichern, weshalb ich die Eigenschaft “Pizza” oben als “string” angegeben habe. Extbase bringt jedoch keinen Konverter mit, mit dem man ein Array in einen String konvertieren kann. Wir haben nun entweder die Möglichkeit unseren eigenen TypeConverter zu programmieren, oder aber teilen dem Property Mapper mit, dass er den Typ “Array” beibehalten soll:

Nun landen unsere Werte für unsere Pizza 1zu1 als Array in dem Setter unseres Domainmodels setPizza(). Hier können wir uns nun selbst um die Konvertierung kümmern:

Jetzt endlich klappt auch die Speicherung und unser Domainmodel “Person” wird korrekt befüllt:

StefanFroemken\Sfpm2\Domain\Model\Personprototypetransient entity
   firstName => 'Stefan' (6 chars)
   lastName => 'Frömken' (8 chars)
   age => 35 (integer)
   pizza => 'Salami,Paprika,Pilze' (20 chars)
   uid => NULL
   _localizedUid => NULL
   _languageUid => NULL
   _versionedUid => NULL
   pid => NULL

Die Eigenschaft “Pizza” im Domainmodel lassen wir aber weiterhin bestehen, denn wir können mit Hilfe des Property Mappers bestimmen welches Formularfeld auf welche Domaineigenschaft gemapped werden soll:

Obwohl jetzt alle Eigenschaften des Formulars erlaubt sind, kommt noch eine Exception:

#1297759968: Exception while property mapping at property path “partner”:Creation of objects not allowed. To enable this, you need to set the PropertyMappingConfiguration Value “CONFIGURATION_CREATION_ALLOWED” to TRUE

Auf Grund von Sicherheit ist es im neuen Property Mapper nicht erlaubt Unterobjekte zu erzeugen. Dies muss explizit erlaubt werden:

Wenn Ihr später die Daten des Partner ändern wollt, dann müsst Ihr auch das Bearbeiten explizit erlauben. Und wenn Ihr einer Person während des Bearbeiten das erste Mal einen neuen Partner zuordnet, dann müsst Ihr auch das Anlegen von Unterobjekten beim Update (initializeUpdateAction) erlauben:

Nach dem Ansenden des Formulars hagelt es wieder eine Exception:

#1297759968: Exception while property mapping at property path “partner”:It is not allowed to map property “0”. You need to use $propertyMappingConfiguration->allowProperties(‘0’) to enable mapping

Ihr seht schon wohin das Problem führt. Wenn wir die Felder für einen Partner z.B. mit Hilfe von jQuery so oft hintereinander anlegen lassen, wie die Person Partner hat, dann müssten wir für jeden weiteren Partner eine weitere allowProperties-Zeile im Controller schreiben. Das kann keine Lösung sein. Deshalb hat das Flow-Team den Stern als Platzhalter für mehrere Elemente eingeführt:

Es muss für jede Untereigenschaft eine Konfiguration angelegt werden. Normalerweile übernimmt Extbase diese Aufgabe für uns, aber bei selbstgebauten Formularfeldern, müssen wir diese selbst erstellen. Unterstützend wirkt hier die Methode forProperty(). Hier kann ein Propertypath angegeben werden. So wäre es z.B. möglich hier “auto.reifen.felge.hersteller” anzugeben. Für jede Eigenschaft in diesem Pfad legt forProperty automatisch eine Property Mapper Konfiguration an. Und mit allowProperties() können wir direkt auf diese neu angelegte Konfiguration zugreifen und bestimmte Eigenschaften direkt erlauben. Auch die Befehle für das Erlauben und Bearbeiten von Unterobjekte kann mit der Pfadsyntax umgehen.