Translations
Info
All page names need to be in English.
en da  de  fr  it  ja  km  nl  ru  zh

De:Extbase/Access and validate GetPostVars

From TYPO3Wiki
Jump to: navigation, search

extbase (Liste extbase) Innerhalb von TYPO3 gibt es viele Möglichkeiten, um auf benötigte GET/POST-Variablen zuzugreifen, aber wer die TYPO3-API kennt, wird schnell merken, dass direkte Zugriffe via $_GET bzw. $_POST eher unerwünscht sind. Zwar gibt es auch mit Hilfe der TYPO3-API die Möglichkeit auf diese Variablen zuzugreifen, aber zuvor wird der Inhalt noch mit stripSlashes() bearbeitet.

GET/POST piBase

Zu Zeiten von Extensions auf piBase-Basis mussten alle für die aktuelle Extension benötigten GET/POST-Variablen mit tx_[Extensionname] geprefixed werden. Nur wenn der Prefix übereinstimmt, wurden die Variablen in $this->piVars zur Verfügung gestellt.

GET/POST extbase

Innerhalb von Extbase gibt es ähnlich der piBase-Variante auch eine Möglichkeit auf die für die Extension gültigen GET/POST-Variablen zuzugreifen. Allerdings ist dies nun noch detaillierter ausgearbeitet. So reicht es zum Beispiel nicht mehr nur tx_myExt als Prefix zu verwenden, sondern man muss auch noch den Pluginnamen diesem Prefix anhängen: tx_myExt_myPluginName.

Schlechtes Beispiel

Nehmen wir folgendes Formularfeld als Grundlage:

XML / HTML:
<input type="text" name="autoMarke" />

Innerhalb von Extbase steht mir keine saubere Möglichkeit zur Verfügung um an den Wert von autoMarke dranzukommen. Mit bleibt nur t3lib_div::_GP('autoMarke').

Beispiel: Text an Action

Wenn wir unser Beispiel von oben etwas erweitern, können wir mit Hilfe von Actions auf diese Werte zugreifen:

XML / HTML:
<input type="text" name="tx_auto_pi1[autoMarke]" />
<input type="text" name="tx_auto_pi1[autoFarbe]" />
<input type="text" name="tx_auto_pi1[autoPs]" />
PHP script:
/**
 * @param string $autoMarke
 * @param string $autoFarbe
 * @param integer $autoPs
 * @return void
 */
public function createAction($autoMarke, $autoFarbe, $autoPs) {
  t3lib_utility_Debug::debug($autoMarke, 'marke');
  t3lib_utility_Debug::debug($autoFarbe, 'farbe');
  t3lib_utility_Debug::debug($autoPs, 'ps');
  die('Ende');
}

Wie Ihr seht, könnt Ihr ohne Verwendung von irgendwelchen API-Methoden auf die GET/POST-Variablen zugreifen. Wichtig dabei ist, das Ihr den richtigen Prefix für Eure Extension/Plugin angegeben habt (tx_myExt_myPluginName) und das der Variablenname exakt übereinstimmt. Vorteil: Über die PHPDoc-Annotation @param könnt Ihr pro Parameter exakt bestimmen, um was für einen Variablentypen es sich handelt. Auch wenn dieses Beispiel schon ganz gut funktioniert, so bringt Es auch einen Nachteil mit sich: Was, wenn Ihr in Eurem Formular 30 Felder habt? Dann müsstet Ihr für die Action 30 Parameter definieren. Das wird unübersichtlich und somit kaum wartbar. Besser wäre es, wenn man die Werte als Array überträgt.

Beispiel: Array an Action

Um dem Problem von oben entgegen zu wirken zeige ich Euch hier eine Möglichkeit, wie man die Formulardaten als Array an eine Action übergeben kann:

XML / HTML:
<input type="text" name="tx_sffluid_sffluid[auto][marke]">
<input type="text" name="tx_sffluid_sffluid[auto][farbe]">
<input type="text" name="tx_sffluid_sffluid[auto][ps]">
PHP script:
/**
 * @param array $auto
 * @return void
 */
public function createAction(array $auto) {
  t3lib_utility_Debug::debug($auto, 'auto');
  die('Ende');
}

Auch diese Variante funktioniert. Vorteil: Wir haben nur einen Parameter in der Actionmethode. Nachteil: Ich müsste nun innerhalb der actionMethode prüfen, ob es sich bei PS wirklich um einen Integer handelt und diesen bei Bedarf entsprechend umwandeln. Um nun beide oberen Varianten zu vereinen gibt es die Möglichkeit das übergebene Array in ein Model umzuwandeln.

Beispiel: Model an Action

Um dem Problem von oben entgegen zu wirken zeige ich Euch hier eine Möglichkeit, wie man die Formulardaten als Model an eine Action übergeben kann:

XML / HTML:
<input type="text" name="tx_sffluid_sffluid[auto][marke]">
<input type="text" name="tx_sffluid_sffluid[auto][farbe]">
<input type="text" name="tx_sffluid_sffluid[auto][ps]">
PHP script:
/**
 * @param Tx_Auto_Domain_Model_Auto $auto
 * @return void
 */
public function createAction(Tx_Auto_Domain_Model_Auto $auto) {
  t3lib_utility_Debug::debug($auto->getMarke(), 'marke');
  t3lib_utility_Debug::debug($auto->getFarbe(), 'farbe');
  t3lib_utility_Debug::debug($auto->getPs(), 'ps');
  die('Ende');
}

Ihr sehr, dass ich am Formular nichts verändert habe. Demnach kommt auch jetzt wieder ein Array bei unserer Action an. Aber bevor diese aufgerufen wird, funkt uns Extbase noch kurz dazwischen. Vor jedem Actionaufruf ließt Extbase zuvor unseren Controller und sucht nach der aufzurufenden ActionMethode. Wurde diese gefunden, werden die enthaltenen Parameter ausgelesen. Stimmt jetzt ein Actionparameter mit einer GET/POST-Variable überein (in unserem Falle auto), dann wird versucht, diese Variable als DEN Variablentypen innerhalb der Action verfügbar zu machen, wie diese mit DEM Variablentypen vor der Variable deklariert wurde (hier: Tx_Auto_Domain_Model_Auto). Hätten wir statt Tx_Auto_Domain_Model_Auto den Variablentypen Array angegeben, dann könnten wir innerhalb der Actionmethode wieder mit allen PHP-Array-Funktionen auf diese Variable zugreifen. In diesem Beispiel ahben wir uns aber für die Model-Variante entschieden und haben somit ein Objekt innerhalb der ActionMethode und können nun nur noch mit Hilfe der definierted getter und setter-Methoden auf unsere Objekteigenschaften marke, farbe und ps zugreifen. Damit das Beispiel funktioniert, müsst Ihr zuvor ein Model erstellen, das die drei Eigenschaften marke, farbe und ps enthält. Wichtig ist, dass Ihr auch die Variablentypen pro Eigenschaft in die PHPDoc-Annotations schreibt. Hier ein verkürztes Domainmodel:

PHP script:
/**
 * @var String
 */
protected $marke;
/**
 * @var String
 */
protected $farbe;
/**
 * @var Integer
 */
protected $ps;

getter /setter Methoden

Vorteil dieser Variante: Wenn wir für PS hallo, also ein Text, angegeben, dann kann dieser Wert auf Grund der Integerangabe innerhalb des Models nicht abgespeichert werden und somit ist das komplette Model nicht mehr valide und die Action kann nicht aufgerufen werden. In diesem Fall wird versucht die zuletzt aufgerufene Action aufzurufen. Schlägt auch das fehl, dann wird die Standardaction (meist: index) aufgerufen. Schlägt auch das wiederum fehl wird die StandardAction so oft aufgerufen, bis diese 100 mal aufgerufen wurde und eine Fehlermeldung (Exception) im FE angezeigt wird.