Der neue Property Mapper

Was ist die Aufgabe eines Property Mappers?

Ein Property Mapper hat die Aufgabe, die Daten, die von Formularen an den Webserver gesendet werden in die korrekten Variablentypen zu konvertieren. Alle Daten eines Formulars werden entweder mit Hilfe von POST oder GET (Url) an den Server übertragen, aber diese Transportmethoden können nur mit Arrays und Texten umgehen. Wenn Ihr also in Eurem Formular ein Feld für das Alter einer Person habt und absendet, dann ist für den Server dieses Alter grundsätzlich erstmal ein Text und keine Zahl. Vielleicht habt Ihr aber auch ein Formular auf Eurer Webseite, auf dem Ihr die Beläge Eurer Pizza zusammenstellen könnt (Auswahl per Checkbox). In diesem Fall werden die Daten als Array an der Server übertragen. Solange diese Transportmethoden nicht zwischen Text und Zahl oder auch Array und Objekten unterscheiden können, seid Ihr die Einzigen die wissen von welchem Typ diese Daten sind. Ein Property Mapper kann Euch bei dieser Aufgabe helfen.

Der bisherige Property Mapper

Der bisherige Property Mapper hilft Euch allerhöchstens dabei ein Array in ein Objekt zu konvertieren. Auch die Konvertierung eines Timestamps in ein DateTime-Object ist enthalten, aber alle anderen Werte werden so wie sie sind einfach an die Settermethoden des Domainmodels weitergereicht und wenn Ihr Euch hier nicht selbst um die Konvertierung kümmert, dann landen weiterhin Texte in Eigenschaften, die eigentlich Zahlenwerte sein sollten. Besten Beispiel: Das Alter einer Person.

Was unterscheidet den neuen Property Mapper vom Alten?

Der neue Property Mapper ist ein Backport von TYPO3 Flow und bietet Euch eine sehr detaillierte Möglichkeit genau entscheiden zu können, welche Variablen der Transportmethoden (POST, GET) in einen bestimmten Datentyp konvertiert werden sollen. Ihr könnt also genau angeben, dass die Variable "Alter", die per Default als Text übertragen wird in einen Integerwert konvertiert werden soll. Ihr könnt auch angeben, dass die Variable "Alter" auf die Eigenschaft "Age" Eures Domainmodels gemapped werden soll. Und wenn Ihr mal gar keine Konfiguration angebt, dann wird der Datentyp anhand der Eigenschaft im Domainmodel abgefragt und verwendet. Über einen Hook könnt Ihr sogar eigene TypeConverter registrieren und verwenden. Ihr seht: Ihr habt alles selbst in der Hand, die Frage ist nur, wie konfiguriert man den Property Mapper. Darüber handelt die nachfolgende Dokumentation.

Aktivieren des neuen Property Mappers

Den neuen Property Mapper gibt es seit TYPO3 4.7 und kann folgendermaßen aktiviert werden:

 

plugin.tx_[euerExtensionName].features.rewrittenPropertyMapper = 1

 

Ab TYPO3 6.1 ist der Property Mapper per Default aktiviert. Wer mag kann die TypoScript-Eigenschaft von oben wieder auf 0 setzen, um weiterhin die alte Variante zu aktivieren. Ab TYPO3 7.0 ist dann aber wirklich Schluss. Hier wurde der alte Property Mapper komplett entfernt und Ihr müsst Euch mit dem neuen Property Mapper begnügen.

Analyse des Request

Ich habe hier mal ein kleines Formular mit Fluid zusammen gebaut:

	
<f:form action="create" name="person" object="{person}">
  <dl>
    <dt><f:translate key="tx_sfpm2_domain_model_person.first_name" /></dt>
    <dd><f:form.textfield property="firstName" /></dd>
  </dl>
  <dl>
    <dt><f:translate key="tx_sfpm2_domain_model_person.last_name" /></dt>
    <dd><f:form.textfield property="lastName" /></dd>
  </dl>
  <dl>
    <dt><f:translate key="tx_sfpm2_domain_model_person.age" /></dt>
    <dd><f:form.textfield property="age" /></dd>
  </dl>
  <dl>
    <dt>&nbsp;</dt>
    <dd><f:form.submit value="Speichern" /></dd>
  </dl>
</f:form>

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.

Konvertierung anhand Domainmodel

Bisher haben wir den Property Mapper noch überhaupt nicht konfiguriert. Somit greift er per Default auf das Domainmodel zu und extrahiert sich mit Hilfe der ReflectionClass von PHP die Datentypen von den enthaltenen Eigenschaften. Hier mal ein Beispiel, wie die Eigenschaften bei mir aussehen:

	
/**
 * FirstName
 *
 * @var string
 */
protected $firstName;
/**
 * LastName
 *
 * @var string
 */
protected $lastName;
/**
 * Age
 *
 * @var integer
 */
protected $age;

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.

Überschreiben der Datentypen

In den bisherigen Beispielen kümmert sich der Property Mapper automatisch um die richtige Konvertierung der ankommenden Daten. Hin und wieder kann es vorkommen, dass Ihr diese Datentypen überschreiben wollt. Im Folgenden wollen wir die Eigenschaft "age" in einen Text konvertieren. Da die automatische Konvertierung noch VOR dem Aufruf unserer Action geschieht, müssen wir uns mit einer initializeAction begnügen. Diese Actions werden noch VOR der Konvertierung durch des Property Mapper ausgeführt. Der ideale Platz, um dem Property Mapper besondere Konvertierungsangaben mitzuliefern:

	
/**
 * initialize create action
 *
 * @return void
 */
public function initializeCreateAction() {
  if ($this->arguments->hasArgument('person')) {
    $this->arguments->getArgument('person')->getPropertyMappingConfiguration()->setTargetTypeForSubProperty('age', 'string');
  }
}

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

Überspringen von Eigenschaften

Ich bin mir gerade unsicher, aber in Deutschland dürfen die Kreditkartennummern und/oder der Überprüfungscode nicht abgespeichert werden. Dennoch gehört die Kreditkarte einer Person. Wir müssen also ein Feld in unser Formular aufnehmen, dass die Kreditkartennummer aufnehmen kann:

	
<dl>
  <dt><f:translate key="tx_sfpm2_domain_model_person.creditCard" /></dt>
  <dd><f:form.textfield property="creditCard" /></dd>
</dl>

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:

	
/**
 * initialize create action
 *
 * @return void
 */
public function initializeCreateAction() {
  if ($this->arguments->hasArgument('person')) {
    $this->arguments->getArgument('person')->getPropertyMappingConfiguration()->skipProperties('creditCard');
  }
}

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:

	
$person = $this->getControllerContext()->getRequest()->getArgument('person');
$creditCard = $person['creditCard'];

Ausbruch aus der Konvention

Extbase ist voll von Konventionen/Vorgaben. Wenn Euer Repository "Person" heißt, dann muss auch das Domainmodel "Person" heißen. Wenn Euer Controller "Auto" heißt, dann muss "Auto" auch im Templatepfad enthalten sein. Auch Actionnamen spiegeln sich in den Templatenamen wieder. Wer aus diesen Konventionen ausbricht hat's schwer uns sollte genau wissen, was er tut. Im Folgenden ein Beispiel, um eine Pizza mit verschiedenen Belägen zusammen zu stellen. Wir fügen Folgende Zeilen in unser Fluid Template:

	
<dl>
  <dt><f:translate key="tx_sfpm2_domain_model_person.pizza" /></dt>
  <dd>
    <f:form.checkbox property="pizza" value="Salami" /> Salami<br />
    <f:form.checkbox property="pizza" value="Schinken" /> Schinken<br />
    <f:form.checkbox property="pizza" value="Paprika" /> Paprika<br />
    <f:form.checkbox property="pizza" value="Pilze" /> Pilze<br />
  </dd>
</dl>

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:

	
<dl>
  <dt><f:translate key="tx_sfpm2_domain_model_person.pizza" /></dt>
  <dd>
    <f:form.checkbox property="pizza[]" value="Salami" /> Salami<br />
    <f:form.checkbox property="pizza[]" value="Schinken" /> Schinken<br />
    <f:form.checkbox property="pizza[]" value="Paprika" /> Paprika<br />
    <f:form.checkbox property="pizza[]" value="Pilze" /> Pilze<br />
  </dd>
</dl>

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:

	
<dl>
  <dt><f:translate key="tx_sfpm2_domain_model_person.pizza" /></dt>
  <dd>
    <input type="checkbox" name="tx_sfpm2_pm2[person][pizza][]" value="Salami" /> Salami<br />
    <input type="checkbox" name="tx_sfpm2_pm2[person][pizza][]" value="Schinken" /> Schinken<br />
    <input type="checkbox" name="tx_sfpm2_pm2[person][pizza][]" value="Paprika" /> Paprika<br />
    <input type="checkbox" name="tx_sfpm2_pm2[person][pizza][]" value="Pilze" /> Pilze
  </dd>
</dl>

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:

	
/**
 * initialize create action
 *
 * @return void
 */
public function initializeCreateAction() {
  if ($this->arguments->hasArgument('person')) {
    $this->arguments->getArgument('person')->getPropertyMappingConfiguration()->allowProperties('pizza');
  }
}

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:

	
/**
 * Pizza
 *
 * @var string
 */
protected $pizza;

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:

	
/**
 * initialize create action
 *
 * @return void
 */
public function initializeCreateAction() {
  if ($this->arguments->hasArgument('person')) {
    $this->arguments->getArgument('person')->getPropertyMappingConfiguration()->allowProperties('pizza');
    $this->arguments->getArgument('person')->getPropertyMappingConfiguration()->setTargetTypeForSubProperty('pizza', 'array');
  }
}

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:

	
/**
 * Returns the pizza
 *
 * @return array $pizza
 */
public function getPizza() {
  return explode(',', $this->pizza);
}

/**
 * Sets the pizza
 *
 * @param array $pizza
 * @return void
 */
public function setPizza(array $pizza) {
  $this->pizza = implode(',', $pizza);
}

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

Mapping auf andere Eigenschaft

Im oberen Beispiel habe ich die Eigenschaft "Pizza" genannt, obwohl es sich eigentlich um den "Belag" handelt. Deshalb ändere ich das Template entsprechend ab:

	
<dl>
  <dt><f:translate key="tx_sfpm2_domain_model_person.pizza" /></dt>
  <dd>
    <input type="checkbox" name="tx_sfpm2_pm2[person][belag][]" value="Salami" /> Salami<br />
    <input type="checkbox" name="tx_sfpm2_pm2[person][belag][]" value="Schinken" /> Schinken<br />
    <input type="checkbox" name="tx_sfpm2_pm2[person][belag][]" value="Paprika" /> Paprika<br />
    <input type="checkbox" name="tx_sfpm2_pm2[person][belag][]" value="Pilze" /> Pilze
  </dd>
</dl>

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:

	
/**
 * initialize create action
 *
 * @return void
 */
public function initializeCreateAction() {
  if ($this->arguments->hasArgument('person')) {
    $this->arguments->getArgument('person')->getPropertyMappingConfiguration()->allowProperties('pizza');
    $this->arguments->getArgument('person')->getPropertyMappingConfiguration()->setTargetTypeForSubProperty('pizza', 'array');
    $this->arguments->getArgument('person')->getPropertyMappingConfiguration()->setMapping('belag', 'pizza');
  }
}

Unterobjekte erlauben

Alles was jetzt kommt kann Extbase von Haus aus alleine. Es gibt nur schon mal Konstellationen, da muss das Formular eben selbst gebaut werden. Um einen solchen Fall nachzustellen, setzen wir das Domainmodel "Person" als z.B. Ehepartner in Relation zu ebenfalls "Person". Für diesen Fall fügen wir nun noch den Vor- und Nachnamen des Ehepartners unserer Person hinzu:

	
<dl>
  <dt><f:translate key="tx_sfpm2_domain_model_person.first_name" /></dt>
  <dd><input type="text" name="tx_sfpm2_pm2[person][partner][firstName]" /></dd>
</dl>
<dl>
  <dt><f:translate key="tx_sfpm2_domain_model_person.last_name" /></dt>
  <dd><input type="text" name="tx_sfpm2_pm2[person][partner][lastName]" /></dd>
</dl>

Da wir hier wieder einmal mit einer Eigenimplementation arbeiten, können die Eigenschaften firstName und lastName nicht dem versteckten Formularfeld __trustedProperties hinzugefügt werden. Extbase kann dadurch kein Mapping für die Formularfelder zu den Eigenschaften in den Domainmodellen erstellen. Die Exception, die jetzt allerdings erscheint, schweift von der Exception von oben ab:

#1297759968: Exception while property mapping at property path "":It is not allowed to map property "partner". You need to use $propertyMappingConfiguration->allowProperties('partner') to enable mapping of this property.

Wir machen mal genau das, was uns die Exception vorschlägt:

$this->arguments->getArgument('person')->getPropertyMappingConfiguration()->allowProperties('partner');

Es resultiert in die nächste Exception:

#1297759968: Exception while property mapping at property path "partner":It is not allowed to map property "firstName". You need to use $propertyMappingConfiguration->allowProperties('firstName') to enable mapping of this property.

Die Exception kennen wir noch von weiter oben und fügen das fehlende Mapping der Felder hin

	
$this->arguments->getArgument('person')->getPropertyMappingConfiguration()->allowProperties('partner');
$this->arguments->getArgument('person')->getPropertyMappingConfiguration()->forProperty('partner')->allowProperties('firstName', 'lastName');

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:

	
$this->arguments->getArgument('person')->getPropertyMappingConfiguration()->allowProperties('partner');
$this->arguments->getArgument('person')->getPropertyMappingConfiguration()->forProperty('partner')->allowProperties('firstName', 'lastName');
$this->arguments->getArgument('person')->getPropertyMappingConfiguration()->allowCreationForSubProperty('partner');

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:

	
$this->arguments->getArgument('person')->getPropertyMappingConfiguration()->allowProperties('partner');
$this->arguments->getArgument('person')->getPropertyMappingConfiguration()->forProperty('partner')->allowProperties('firstName', 'lastName');
$this->arguments->getArgument('person')->getPropertyMappingConfiguration()->allowCreationForSubProperty('partner');
$this->arguments->getArgument('person')->getPropertyMappingConfiguration()->allowModificationForSubProperty('partner');

Mehrere Unterobjekte erlauben mit Stern (*)

Wir treiben den Wahnsinn noch etwas weiter. Auch wenn ich nicht unbedingt der Fan davon bin, so wollen wir es nun erlauben, dass unsere Person mehrere Partner haben kann. Dazu ändern wir zunächst wieder das Fluidtemplate:

	
<dl>
  <dt><f:translate key="tx_sfpm2_domain_model_person.first_name" /></dt>
  <dd><input type="text" name="tx_sfpm2_pm2[person][partner][0][firstName]" /></dd>
</dl>
<dl>
  <dt><f:translate key="tx_sfpm2_domain_model_person.last_name" /></dt>
  <dd><input type="text" name="tx_sfpm2_pm2[person][partner][0][lastName]" /></dd>
</dl>
<dl>
  <dt><f:translate key="tx_sfpm2_domain_model_person.first_name" /></dt>
  <dd><input type="text" name="tx_sfpm2_pm2[person][partner][1][firstName]" /></dd>
</dl>
<dl>
  <dt><f:translate key="tx_sfpm2_domain_model_person.last_name" /></dt>
  <dd><input type="text" name="tx_sfpm2_pm2[person][partner][1][lastName]" /></dd>
</dl>

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:

	
$this->arguments->getArgument('person')->getPropertyMappingConfiguration()->allowProperties('partners');
$this->arguments->getArgument('person')->getPropertyMappingConfiguration()->forProperty('partners.*')->allowProperties('firstName', 'lastName');
$this->arguments->getArgument('person')->getPropertyMappingConfiguration()->allowCreationForSubProperty('partners.*');
$this->arguments->getArgument('person')->getPropertyMappingConfiguration()->allowModificationForSubProperty('partner.*');

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.