Einfache Anpassung von Umleitungen mit returnTo-Codes

in  Zikula Apps , ,

Einfache Anpassung von Umleitungen mit returnTo-Codes

Bei vielen kleineren Modulen muss nichts oder nicht viel an der Logik verändert werden, welche die Bearbeitung von Datensätzen steuert. Häufig ist es aber wünschenswert, dass der Anwender nach dem Speichern seiner Änderungen zu einer bestimmten Stelle umgeleitet wird. In generierten ModuleStudio-Modulen gibt es dafür bereits eine nützliche Funktion.

Im Folgenden wird ein einfaches Modell als Beispiel verwendet: es gibt zwei Entitäten für Kunden und Adressen. Eine bidirektionale 1:n-Beziehung legt fest, dass jeder Kunde mehrere Adressen haben kann, wobei jede Adresse auch auf die Daten des zugeordneten Kunden zugreifen kann. Als Anwendungsfall erstellen beziehungsweise bearbeiten wir eine Adresse.

In den generierten FormHandlern gibt es jeweils zwei Methoden, die bei der Entscheidung darüber mitwirken, zu welcher Seite der Anwender nach dem Bearbeiten des Datensatzes gelangt: getRedirectUrl() und getDefaultReturnUrl().

Die Methode getRedirectUrl() regelt die Logik zur Bestimmung der für die Umleitung zu verwendenden URL. Aktiviert man beim Erstellen einer neuen Adresse das Häkchen bei der Checkbox “Nach dem Speichern noch einen Eintrag erstellen”, so landet man nach dem Abschicken des Formulars wieder auf genau der gleichen Seite. Ansonsten wird geprüft, ob ein gültiges Umleitungsziel definiert wurde. In allen anderen Fällen wird getDefaultReturnUrl() verwendet.

In der Methode getDefaultReturnUrl() wird das Standardziel definiert, was davon abhängig ist, welche Aktionen der aktuelle Controller besitzt. Wenn beispielsweise keine display-Aktion vorhanden ist, ist es natürlich auch nicht möglich, auf die Detailseite einer Adresse umzuleiten. Per Standard gelangt der Anwender zurück zur Übersicht, also in unserem Beispiel zur Liste der Adressen. Eine Ausnahme bilden Entitäten, die die Tree-Extension aktiviert haben, hier gelangt man per Standard zur Detailseite des entsprechenden Objektes.

Nutzung des returnTo-Parameters

Wie oben bereits erwähnt, prüft die Methode getRedirectUrl(), ob ein gültiges Umleitungsziel definiert wurde. Dies bezieht sich auf einen GET-Parameter namens returnTo, der bei der Verlinkung des Formulars einfach mit übergeben werden kann. Damit kann die Umleitung direkt vom Template aus angepasst werden, so dass in der Regel kein Code verändert werden muss.

<a href="{modurl modname='MeinModul' type='user' func='edit' ot='address' id=123 returnTo='xyz'}">Adresse bearbeiten</a>
<a href="{modurl modname='MeinModul' type='user' func='edit' ot='address' customer=123 returnTo='xyz'}">Adresse hinzufügen</a>

Je nach im Modell vorhandenen Controller-Aktionen wird direkt eine Vielzahl von returnTo-Codes unterstützt. Ein paar Beispiele:

  • admin: Einstiegsseite im Verwaltungsbereich
  • adminDisplay: Detailansicht der Adresse im Verwaltungsbereich
  • userDisplayCustomer: Detailansicht des Kunden im Benutzerbereich
  • adminViewCustomer: Liste der Kunden im Verwaltungsbereich

Weitergehende Anpassungen

Möchte man den Anwender zu einer komplett anderen Seite umleiten oder individuelle Bedingungen in die Entscheidung mit einfließen lassen, so kann man die genannten Methoden anpassen. In der Regel reicht es aus, die Methode getDefaultReturnUrl() in der konkreten und leer generierten FormHandler-Klasse der jeweiligen Entität zu überschreiben. Dies kann beispielsweise so aussehen:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
/**
 * Returns the default redirect url. Required if no returnTo parameter has been supplied.
 * This method is called in handleCommand so we know which command has been performed.
 *
 * @param array $args List of arguments.
 *
 * @return string The default redirect url.
 */
protected function getDefaultReturnUrl($args)
{
    $url = parent::getDefaultReturnUrl($args);
    if ('create' != $this->mode) {
        $url = ModUtil::url('Content', 'user', 'view', array('pid' => 123));
    }

    return $url;
}