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;
}

Weitere Beiträge in Kategorie Zikula Apps

Symfony Messenger - Behandlung erneut fehlgeschlagener Nachrichten
- Im Symfony Messenger gibt die Möglichkeit, fehlgeschlagene Nachrichten an eine failed queue zu leiten. In diesem Sammelbecken können diese dann inspiziert und nach Korrektur des zu Grunde liegenden …
Response-Eigenschaften im Zikula Theme-Layer anpassen
- In Zikula gibt es eine Besonderheit zu beachten, welche Einfluss darauf nimmt, wie die aus einem Request resultierende Response zum anfragenden Client gelangt. Per Standard wird die Response in …
Tabellennamen mit Doctrine dynamisch anpassen
- Mit Hilfe der Metadaten von Doctrine lassen sich jegliche Daten zu einer Entität zur Laufzeit verändern. Allerdings kann das in manchen Anwendungsfällen fortwährend notwendig sein, zum Beispiel in …
Kommende Neuerungen in Symfony 5.2
- Vor zwei Tagen wurde Symfony 5.2.0-BETA2 veröffentlicht. Dies nehme ich zum Anlass, um einmal einen Überblick über die wichtigsten neuen Funktionen zu geben, auf die wir uns im Rahmen dieses Updates …
Zikula Core 3.0.3 mit Sicherheits-Update von Symfony 5
- Vor kurzem hatten wir über das Release von Zikula 3.0.1 berichtet, welches wichtige Korrekturen für Zikula 3 bereitgestellt hat. Vor einer Woche wurde die nächste Version 3.0.2 veröffentlicht. …