Nette Documentation Preview

syntax
Vortragende
***********

<div class=perex>

Wir werden lernen, wie man Presenter und Vorlagen in Nette schreibt. Nach der Lektüre werden Sie wissen:

- wie der Presenter funktioniert
- was persistente Parameter sind
- wie man eine Vorlage rendert

</div>

[Wir wissen bereits, |how-it-works#nette-application] dass ein Presenter eine Klasse ist, die eine bestimmte Seite einer Webanwendung darstellt, z. B. eine Homepage, ein Produkt im E-Shop, ein Anmeldeformular, ein Sitemap-Feed usw. Die Anwendung kann von einem bis zu Tausenden von Presentern haben. In anderen Frameworks werden sie auch als Controller bezeichnet.

Normalerweise bezieht sich der Begriff Presenter auf einen Abkömmling der Klasse [api:Nette\Application\UI\Presenter], die für Web-Interfaces geeignet ist und die wir im weiteren Verlauf dieses Kapitels besprechen werden. Im allgemeinen Sinne ist ein Presenter jedes Objekt, das die Schnittstelle [api:Nette\Application\IPresenter] implementiert.


Lebenszyklus eines Presenters .[#toc-life-cycle-of-presenter]
=============================================================

Die Aufgabe des Presenters besteht darin, die Anfrage zu verarbeiten und eine Antwort zu liefern (die eine HTML-Seite, ein Bild, eine Routing usw. sein kann).

Am Anfang steht also eine Anfrage. Dabei handelt es sich nicht direkt um eine HTTP-Anfrage, sondern um ein [api:Nette\Application\Request] -Objekt, in das die HTTP-Anfrage mithilfe eines Routers umgewandelt wurde. Mit diesem Objekt kommen wir in der Regel nicht in Berührung, da der Präsentator die Verarbeitung der Anfrage geschickt an spezielle Methoden delegiert, die wir jetzt sehen werden.

[* lifecycle.svg *] *** *Lebenszyklus des Presenters* .<>

Die Abbildung zeigt eine Liste von Methoden, die nacheinander von oben nach unten aufgerufen werden, sofern sie existieren. Keine von ihnen muss existieren, wir können einen völlig leeren Presenter ohne eine einzige Methode haben und ein einfaches statisches Web darauf aufbauen.


`__construct()`
---------------

Der Konstruktor gehört nicht direkt zum Lebenszyklus des Präsentators, da er zum Zeitpunkt der Erstellung des Objekts aufgerufen wird. Aber wir erwähnen ihn wegen seiner Bedeutung. Der Konstruktor (zusammen mit der [Methode inject |best-practices:inject-method-attribute]) wird verwendet, um Abhängigkeiten zu übergeben.

Der Presenter sollte sich nicht um die Geschäftslogik der Anwendung kümmern, nicht in die Datenbank schreiben und aus ihr lesen, keine Berechnungen durchführen, usw. Dies ist die Aufgabe für Klassen aus einer Schicht, die wir Modell nennen. Zum Beispiel kann die Klasse `ArticleRepository` für das Laden und Speichern von Artikeln zuständig sein. Damit der Presenter sie verwenden kann, wird sie [mittels Dependency Injection übergeben |dependency-injection:passing-dependencies]:


```php
class ArticlePresenter extends Nette\Application\UI\Presenter
{
	public function __construct(
		private ArticleRepository $articles,
	) {
	}
}
```


`startup()`
-----------

Unmittelbar nach Erhalt der Anfrage wird die Methode `startup ()` aufgerufen. Sie können sie verwenden, um Eigenschaften zu initialisieren, Benutzerrechte zu prüfen, usw. Es ist erforderlich, immer den Vorgänger `parent::startup()` aufzurufen.


`action<Action>(args...)` .{toc: action<Action>()}
--------------------------------------------------

Ähnlich wie bei der Methode `render<View>()`. Während `render<View>()` dazu gedacht ist, Daten für eine bestimmte Vorlage vorzubereiten, die anschließend gerendert wird, wird in `action<Action>()` wird eine Anfrage ohne anschließendes Rendering der Vorlage verarbeitet. So werden z. B. Daten verarbeitet, ein Benutzer an- oder abgemeldet usw., und dann wird er [an eine andere Stelle weitergeleitet |#Redirection].

Es ist wichtig, dass `action<Action>()` vor aufgerufen wird `render<View>()`aufgerufen wird, damit wir darin möglicherweise den weiteren Verlauf des Lebenszyklus ändern können, d. h. die Vorlage, die gerendert wird, und auch die Methode `render<View>()` die aufgerufen wird, mit `setView('otherView')`.

Die Parameter der Anfrage werden an die Methode übergeben. Es ist möglich und empfehlenswert, Typen für die Parameter anzugeben, z. B. `actionShow(int $id, ?string $slug = null)` - wenn der Parameter `id` fehlt oder keine ganze Zahl ist, gibt der Präsentator den [Fehler 404 |#Error 404 etc.] zurück und bricht die Operation ab.


`handle<Signal>(args...)` .{toc: handle<Signal>()}
--------------------------------------------------

Diese Methode verarbeitet die sogenannten Signale, die wir im Kapitel über [Komponenten |components#Signal] besprechen werden. Sie ist hauptsächlich für Komponenten und die Verarbeitung von AJAX-Anfragen gedacht.

Die Parameter werden an die Methode übergeben, wie im Fall von `action<Action>()`übergeben, einschließlich der Typüberprüfung.


`beforeRender()`
----------------

Die Methode `beforeRender` wird, wie der Name schon sagt, vor jeder Methode aufgerufen `render<View>()`. Sie wird für die allgemeine Konfiguration von Vorlagen, die Übergabe von Variablen für das Layout und so weiter verwendet.


`render<View>(args...)` .{toc: render<View>()}
----------------------------------------------

Der Ort, an dem wir die Vorlage für das spätere Rendering vorbereiten, Daten an sie übergeben usw.

Die Parameter werden an die Methode übergeben, wie im Fall von `action<Action>()`übergeben, einschließlich der Typüberprüfung.

```php
public function renderShow(int $id): void
{
	// wir beziehen Daten aus dem Modell und übergeben sie an die Vorlage
	$this->template->article = $this->articles->getById($id);
}
```


`afterRender()`
---------------

Die Methode `afterRender` wird, wie der Name schon sagt, nach jeder `render<View>()` Methode aufgerufen. Sie wird eher selten verwendet.


`shutdown()`
------------

Sie wird am Ende des Lebenszyklus des Präsentators aufgerufen.


**Guter Rat, bevor wir weitermachen**. Wie Sie sehen können, kann der Präsentator mehr Aktionen/Ansichten verarbeiten, d.h. mehr Methoden haben `render<View>()`. Wir empfehlen jedoch, Presenter mit einer oder so wenigen Aktionen wie möglich zu entwerfen.


Senden einer Antwort .[#toc-sending-a-response]
===============================================

Die Antwort des Präsentators ist in der Regel das [Rendern der Vorlage mit der HTML-Seite |templates], aber es kann auch das Senden einer Datei, JSON oder sogar die Routing zu einer anderen Seite sein.

Zu jedem Zeitpunkt des Lebenszyklus können Sie eine der folgenden Methoden verwenden, um eine Antwort zu senden und gleichzeitig den Präsentator zu beenden:

- `redirect()`, `redirectPermanent()`, `redirectUrl()` und `forward()` [leitet um |#Redirection]
- `error()` verlässt den Präsentator [aufgrund eines Fehlers |#Error 404 etc.]
- `sendJson($data)` verlässt den Presenter und [sendet die Daten |#Sending JSON] im JSON-Format
- `sendTemplate()` verlässt den Presenter und [rendert |templates] sofort [die Vorlage |templates]
- `sendResponse($response)` verlässt den Präsentator und sendet [eine eigene Antwort |#Responses]
- `terminate()` verlässt den Präsentator ohne Antwort

Wenn Sie keine dieser Methoden aufrufen, fährt der Presenter automatisch mit dem Rendern der Vorlage fort. Und warum? Nun, weil wir in 99% der Fälle eine Vorlage zeichnen wollen, also nimmt der Präsentator dieses Verhalten als Standard an und will uns die Arbeit erleichtern.


Links erstellen .[#toc-creating-links]
======================================

Presenter hat eine Methode `link()`, die verwendet wird, um URL-Links zu anderen Presentern zu erstellen. Der erste Parameter ist der Zielmoderator und die Aktion, gefolgt von den Argumenten, die als Array übergeben werden können:

```php
$url = $this->link('Product:show', $id);

$url = $this->link('Product:show', [$id, 'lang' => 'en']);
```

In der Vorlage erstellen wir Links zu anderen Präsentatoren und Aktionen wie folgt:

```latte
<a n:href="Product:show $id">product detail</a>
```

Schreiben Sie einfach das bekannte Paar `Presenter:action` anstelle der echten URL und fügen Sie beliebige Parameter ein. Der Trick ist `n:href`, das besagt, dass dieses Attribut von Latte verarbeitet wird und eine echte URL erzeugt. In Nette müssen Sie überhaupt nicht über URLs nachdenken, sondern nur über Presenter und Aktionen.

Weitere Informationen finden Sie unter [Links erstellen |Creating Links].


Umleitung .[#toc-redirection]
=============================

Die Methoden `redirect()` und `forward()` werden verwendet, um zu einem anderen Präsentator zu springen. Sie haben eine sehr ähnliche Syntax wie die Methode [link() |#Creating Links].

Die `forward()` schaltet ohne HTTP-Umleitung sofort auf den neuen Präsentator um:

```php
$this->forward('Product:show');
```

Beispiel für eine so genannte temporäre Umleitung mit HTTP-Code 302 (oder 303, wenn die aktuelle Anfragemethode POST ist):

```php
$this->redirect('Product:show', $id);
```

Um eine dauerhafte Umleitung mit HTTP-Code 301 zu erreichen, verwenden Sie:

```php
$this->redirectPermanent('Product:show', $id);
```

Sie können mit der Methode `redirectUrl()` zu einer anderen URL außerhalb der Anwendung umleiten. Der HTTP-Code kann als zweiter Parameter angegeben werden, wobei der Standardwert 302 ist (oder 303, wenn die aktuelle Anforderungsmethode POST ist):

```php
$this->redirectUrl('https://nette.org');
```

Die Umleitung beendet sofort den Lebenszyklus des Präsentators, indem sie die sogenannte Silent Termination Exception `Nette\Application\AbortException` auslöst.

Vor der Routing ist es möglich, eine [Flash-Nachricht |#Flash Messages] zu senden, die nach der Routing in der Vorlage angezeigt wird.


Flash-Nachrichten .[#toc-flash-messages]
========================================

Dies sind Meldungen, die in der Regel über das Ergebnis eines Vorgangs informieren. Ein wichtiges Merkmal von Flash-Meldungen ist, dass sie auch nach einer Routing in der Vorlage verfügbar sind. Selbst nachdem sie angezeigt wurden, bleiben sie noch 30 Sekunden lang erhalten - zum Beispiel für den Fall, dass der Benutzer die Seite unbeabsichtigt aktualisiert - die Nachricht geht nicht verloren.

Rufen Sie einfach die Methode [flashMessage() |api:Nette\Application\UI\Control::flashMessage()] auf und Presenter kümmert sich um die Übergabe der Nachricht an die Vorlage. Das erste Argument ist der Text der Nachricht und das zweite optionale Argument ist ihr Typ (Fehler, Warnung, Info usw.). Die Methode `flashMessage()` gibt eine Instanz von flash message zurück, damit wir weitere Informationen hinzufügen können.

```php
$this->flashMessage('Item was removed.');
$this->redirect(/* ... */);
```

In der Vorlage sind diese Meldungen in der Variablen `$flashes` als Objekte `stdClass` verfügbar, die die Eigenschaften `message` (Meldungstext) und `type` (Meldungstyp) enthalten und die bereits erwähnten Benutzerinformationen enthalten können. Wir zeichnen sie wie folgt:

```latte
{foreach $flashes as $flash}
	<div class="flash {$flash->type}">{$flash->message}</div>
{/foreach}
```


Fehler 404 usw. .[#toc-error-404-etc]
=====================================

Wenn wir die Anfrage nicht erfüllen können, weil z.B. der Artikel, den wir anzeigen wollen, nicht in der Datenbank existiert, werden wir den Fehler 404 mit der Methode `error(?string $message = null, int $httpCode = 404)` ausgeben, die den HTTP-Fehler 404 darstellt:

```php
public function renderShow(int $id): void
{
	$article = $this->articles->getById($id);
	if (!$article) {
		$this->error();
	}
	// ...
}
```

Der HTTP-Fehlercode kann als zweiter Parameter übergeben werden, der Standardwert ist 404. Die Methode funktioniert, indem sie die Ausnahme `Nette\Application\BadRequestException` auslöst, woraufhin `Application` die Kontrolle an den Fehler-Moderator weitergibt. Dabei handelt es sich um einen Presenter, dessen Aufgabe es ist, eine Seite anzuzeigen, die über den Fehler informiert.
Der Fehler-Presenter wird in der [Anwendungskonfiguration |configuration] festgelegt.


Senden von JSON .[#toc-sending-json]
====================================

Beispiel für eine Action-Methode, die Daten im JSON-Format sendet und den Präsentator verlässt:

```php
public function actionData(): void
{
	$data = ['hello' => 'nette'];
	$this->sendJson($data);
}
```


Parameter anfordern .[#toc-request-parameters]
==============================================

Der Präsentator, wie auch jede Komponente, bezieht seine Parameter aus der HTTP-Anfrage. Ihre Werte können mit der Methode `getParameter($name)` oder `getParameters()` abgerufen werden. Bei den Werten handelt es sich um Strings oder Arrays von Strings, also im Wesentlichen um Rohdaten, die direkt aus der URL bezogen werden.

Für zusätzlichen Komfort empfiehlt es sich, die Parameter über Eigenschaften zugänglich zu machen. Beschriften Sie sie einfach mit dem `#[Parameter]` Attribut:

```php
use Nette\Application\Attributes\Parameter;  // diese Zeile ist wichtig

class HomePresenter extends Nette\Application\UI\Presenter
{
	#[Parameter]
	public string $theme; // muss öffentlich sein
}
```

Für Eigenschaften empfehlen wir die Angabe des Datentyps (z. B. `string`). Nette wird den Wert dann automatisch auf der Grundlage dieses Typs umwandeln. Parameterwerte können auch [validiert |#Validation of Parameters] werden.

Beim Erstellen einer Verknüpfung können Sie den Wert für die Parameter direkt festlegen:

```latte
<a n:href="Home:default theme: dark">click</a>
```


Dauerhafte Parameter .[#toc-persistent-parameters]
==================================================

Persistente Parameter werden verwendet, um den Zustand zwischen verschiedenen Anfragen zu erhalten. Ihr Wert bleibt gleich, auch wenn ein Link angeklickt wird. Im Gegensatz zu Sitzungsdaten werden sie in der URL übergeben. Dies geschieht völlig automatisch, so dass es nicht notwendig ist, sie in `link()` oder `n:href` explizit anzugeben.

Beispiel für die Verwendung? Sie haben eine mehrsprachige Anwendung. Die aktuelle Sprache ist ein Parameter, der immer Teil der URL sein muss. Es wäre aber unglaublich mühsam, ihn in jeden Link aufzunehmen. Also machen Sie ihn zu einem dauerhaften Parameter mit dem Namen `lang` und er wird sich selbst tragen. Toll!

Das Erstellen eines dauerhaften Parameters ist in Nette extrem einfach. Erstellen Sie einfach eine öffentliche Eigenschaft und kennzeichnen Sie sie mit dem Attribut: (früher wurde `/** @persistent */` verwendet)

```php
use Nette\Application\Attributes\Persistent; // diese Zeile ist wichtig

class ProductPresenter extends Nette\Application\UI\Presenter
{
	#[Persistent]
	public string $lang; // muss öffentlich sein
}
```

Wenn `$this->lang` einen Wert wie `'en'` hat, dann werden Links, die mit `link()` oder `n:href` erstellt werden, auch den Parameter `lang=en` enthalten. Und wenn der Link angeklickt wird, wird er wieder `$this->lang = 'en'` sein.

Für Eigenschaften wird empfohlen, den Datentyp anzugeben (z. B. `string`), und Sie können auch einen Standardwert angeben. Parameterwerte können [validiert |#Validation of Parameters] werden.

Persistente Parameter werden standardmäßig zwischen allen Aktionen eines bestimmten Präsentators weitergegeben. Um sie zwischen mehreren Präsentatoren zu übergeben, müssen Sie sie entweder definieren:

- in einem gemeinsamen Vorfahren, von dem die Präsentatoren erben
- in der Eigenschaft, die die Präsentatoren verwenden:

```php
trait LanguageAware
{
	#[Persistent]
	public string $lang;
}

class ProductPresenter extends Nette\Application\UI\Presenter
{
	use LanguageAware;
}
```

Sie können den Wert eines dauerhaften Parameters ändern, wenn Sie einen Link erstellen:

```latte
<a n:href="Product:show $id, lang: cs">detail in Czech</a>
```

Oder er kann *zurückgesetzt* werden, d.h. aus der URL entfernt werden. Er nimmt dann seinen Standardwert an:

```latte
<a n:href="Product:show $id, lang: null">click</a>
```


Interaktive Komponenten .[#toc-interactive-components]
======================================================

Presenter haben ein eingebautes Komponentensystem. Komponenten sind separate, wiederverwendbare Einheiten, die wir in Presenter einfügen. Es kann sich dabei um [Formulare |forms:in-presenter], Datenfelder, Menüs und alles handeln, was für eine wiederholte Verwendung sinnvoll ist.

Wie werden Komponenten im Presenter platziert und anschließend verwendet? Das wird im Kapitel [Komponenten |Components] erklärt. Sie werden sogar erfahren, was sie mit Hollywood zu tun haben.

Wo kann ich einige Komponenten bekommen? Auf der Seite [Componette |https://componette.org] finden Sie einige Open-Source-Komponenten und andere Erweiterungen für Nette, die von der Nette-Framework-Gemeinschaft erstellt und geteilt werden.


Tiefer gehen .[#toc-going-deeper]
=================================

.[tip]
Was wir bisher in diesem Kapitel gezeigt haben, wird wahrscheinlich ausreichen. Die folgenden Zeilen sind für diejenigen gedacht, die sich eingehend mit Moderatoren beschäftigen und alles wissen wollen.


Validierung von Parametern .[#toc-validation-of-parameters]
-----------------------------------------------------------

Die Werte von [Anfrageparametern |#request parameters] und [dauerhaften Parametern |#persistent parameters], die von URLs empfangen werden, werden von der Methode `loadState()` in Eigenschaften geschrieben. Sie prüft auch, ob der in der Eigenschaft angegebene Datentyp übereinstimmt, andernfalls antwortet sie mit einem 404-Fehler und die Seite wird nicht angezeigt.

Verlassen Sie sich niemals blind auf Parameter, da sie leicht vom Benutzer in der URL überschrieben werden können. So überprüfen wir zum Beispiel, ob `$this->lang` zu den unterstützten Sprachen gehört. Eine gute Möglichkeit, dies zu tun, besteht darin, die oben erwähnte Methode `loadState()` zu überschreiben:

```php
class ProductPresenter extends Nette\Application\UI\Presenter
{
	#[Persistent]
	public string $lang;

	public function loadState(array $params): void
	{
		parent::loadState($params); // hier wird die $this->lang gesetzt
		// nach der Prüfung der Benutzerwerte:
		if (!in_array($this->lang, ['en', 'cs'])) {
			$this->error();
		}
	}
}
```


Speichern und Wiederherstellen der Anfrage .[#toc-save-and-restore-the-request]
-------------------------------------------------------------------------------

Die Anfrage, die der Präsentator bearbeitet, ist ein Objekt [api:Nette\Application\Request] und wird von der Methode `getRequest()` des Präsentators zurückgegeben.

Sie können die aktuelle Anfrage in einer Sitzung speichern oder sie aus der Sitzung wiederherstellen und den Präsentator sie erneut ausführen lassen. Dies ist z. B. nützlich, wenn ein Benutzer ein Formular ausfüllt und sein Login abläuft. Um keine Daten zu verlieren, speichern wir vor der Weiterleitung zur Anmeldeseite die aktuelle Anfrage in der Sitzung mit `$reqId = $this->storeRequest()`, die einen Bezeichner in Form eines kurzen Strings zurückgibt und diesen als Parameter an den Anmeldepräsentator übergibt.

Nach der Anmeldung rufen wir die Methode `$this->restoreRequest($reqId)` auf, die die Anfrage aus der Session abholt und an diese weiterleitet. Die Methode prüft, ob die Anfrage von demselben Benutzer erstellt wurde, der jetzt angemeldet ist. Wenn sich ein anderer Benutzer anmeldet oder der Schlüssel ungültig ist, tut sie nichts und das Programm läuft weiter.

Siehe das Kochbuch [How to return to a earlier page |best-practices:restore-request].


Kanonisierung .[#toc-canonization]
----------------------------------

Presenter haben eine wirklich großartige Funktion, die SEO (Optimierung der Auffindbarkeit im Internet) verbessert. Sie verhindern automatisch das Vorhandensein von doppeltem Inhalt unter verschiedenen URLs. Wenn mehrere URLs zu einem bestimmten Ziel führen, z. B. `/index` und `/index?page=1`, bestimmt das Framework eine von ihnen als die primäre (kanonische) und leitet die anderen mit dem HTTP-Code 301 auf diese um. Auf diese Weise werden die Seiten von den Suchmaschinen nicht doppelt indiziert und ihr Page Rank nicht geschwächt.

Dieser Vorgang wird als Kanonisierung bezeichnet. Die kanonische URL ist die vom [Router |routing] generierte URL, in der Regel die erste geeignete Route in der Sammlung.

Die Kanonisierung ist standardmäßig aktiviert und kann über `$this->autoCanonicalize = false` ausgeschaltet werden.

Eine Umleitung findet bei einer AJAX- oder POST-Anfrage nicht statt, da dies zu Datenverlust oder keinem SEO-Mehrwert führen würde.

Sie können die Kanonisierung auch manuell mit der Methode `canonicalize()` aufrufen, die wie die Methode `link()` den Präsentator, Aktionen und Parameter als Argumente erhält. Sie erstellt einen Link und vergleicht ihn mit der aktuellen URL. Wenn sie sich unterscheidet, wird sie auf den erzeugten Link umgeleitet.

```php
public function actionShow(int $id, ?string $slug = null): void
{
	$realSlug = $this->facade->getSlugForId($id);
	// leitet um, wenn $slug nicht mit $realSlug übereinstimmt
	$this->canonicalize('Product:show', [$id, $realSlug]);
}
```


Ereignisse .[#toc-events]
-------------------------

Zusätzlich zu den Methoden `startup()`, `beforeRender()` und `shutdown()`, die im Rahmen des Lebenszyklus des Presenters aufgerufen werden, können weitere Funktionen definiert werden, die automatisch aufgerufen werden. Der Präsentator definiert die sogenannten [Ereignisse |nette:glossary#events], und Sie fügen deren Handler zu den Arrays `$onStartup`, `$onRender` und `$onShutdown` hinzu.

```php
class ArticlePresenter extends Nette\Application\UI\Presenter
{
	public function __construct()
	{
		$this->onStartup[] = function () {
			// ...
		};
	}
}
```

Die Handler im Array `$onStartup` werden kurz vor der Methode `startup()` aufgerufen, dann `$onRender` zwischen `beforeRender()` und `render<View>()` und schließlich `$onShutdown` kurz vor `shutdown()`.


Antworten .[#toc-responses]
---------------------------

Die vom Präsentator zurückgegebene Antwort ist ein Objekt, das die Schnittstelle [api:Nette\Application\Response] implementiert. Es gibt eine Reihe von vorgefertigten Antworten:

- [api:Nette\Application\Responses\CallbackResponse] - sendet einen Rückruf
- [api:Nette\Application\Responses\FileResponse] - sendet die Datei
- [api:Nette\Application\Responses\ForwardResponse] - weiterleiten ()
- [api:Nette\Application\Responses\JsonResponse] - sendet JSON
- [api:Nette\Application\Responses\RedirectResponse] - umleiten
- [api:Nette\Application\Responses\TextResponse] - sendet Text
- [api:Nette\Application\Responses\VoidResponse] - leere Antwort

Antworten werden mit der Methode `sendResponse()` gesendet:

```php
use Nette\Application\Responses;

// Klartext
$this->sendResponse(new Responses\TextResponse('Hello Nette!'));

// Sendet eine Datei
$this->sendResponse(new Responses\FileResponse(__DIR__ . '/invoice.pdf', 'Invoice13.pdf'));

// Sendet einen Rückruf
$callback = function (Nette\Http\IRequest $httpRequest, Nette\Http\IResponse $httpResponse) {
	if ($httpResponse->getHeader('Content-Type') === 'text/html') {
		echo '<h1>Hallo</h1>';
	}
};
$this->sendResponse(new Responses\CallbackResponse($callback));
```


Zugangsbeschränkung mit `#[Requires]` .[#toc-access-restriction-using-requires]{data-version:3.2.2}
---------------------------------------------------------------------------------------------------

Das Attribut `#[Requires]` Attribut bietet erweiterte Optionen zur Einschränkung des Zugriffs auf Präsentatoren und ihre Methoden. Es kann verwendet werden, um HTTP-Methoden zu spezifizieren, AJAX-Anfragen zu verlangen, den Zugriff auf denselben Ursprung zu beschränken und den Zugriff nur auf Weiterleitungen zu beschränken. Das Attribut kann sowohl auf Presenter-Klassen als auch auf einzelne Methoden angewendet werden, z. B. `action<Action>()`, `render<View>()`, `handle<Signal>()`, und `createComponent<Name>()`.

Sie können diese Einschränkungen angeben:
- auf HTTP-Methoden: `#[Requires(methods: ['GET', 'POST'])]`
- die eine AJAX-Anfrage erfordern: `#[Requires(ajax: true)]`
- Zugriff nur vom selben Ursprung: `#[Requires(sameOrigin: true)]`
- Zugriff nur über Weiterleitung: `#[Requires(forward: true)]`
- Einschränkungen für bestimmte Aktionen: `#[Requires(actions: 'default')]`

Für Einzelheiten siehe [Verwendung des Requires Attributs |best-practices:attribute-requires].


HTTP-Methodenprüfung .[#toc-http-method-check]
----------------------------------------------

In Nette überprüfen die Moderatoren die HTTP-Methode jeder eingehenden Anfrage automatisch, hauptsächlich aus Sicherheitsgründen. Standardmäßig sind die Methoden `GET`, `POST`, `HEAD`, `PUT`, `DELETE`, `PATCH` zugelassen.

Wenn Sie zusätzliche Methoden wie `OPTIONS` aktivieren möchten, können Sie das `#[Requires]` Attribut verwenden (ab Nette Application v3.2):

```php
#[Requires(methods: ['GET', 'POST', 'HEAD', 'PUT', 'DELETE', 'PATCH', 'OPTIONS'])]
class MyPresenter extends Nette\Application\UI\Presenter
{
}
```

In Version 3.1 wird die Überprüfung in `checkHttpMethod()` durchgeführt, das prüft, ob die in der Anfrage angegebene Methode im Array `$presenter->allowedMethods` enthalten ist. Fügen Sie eine Methode wie diese hinzu:

```php
class MyPresenter extends Nette\Application\UI\Presenter
{
    protected function checkHttpMethod(): void
    {
        $this->allowedMethods[] = 'OPTIONS';
        parent::checkHttpMethod();
    }
}
```

Es ist wichtig zu betonen, dass, wenn Sie die `OPTIONS` -Methode zulassen, Sie sie auch in Ihrem Präsentator richtig behandeln müssen. Diese Methode wird häufig als so genannte Preflight-Anfrage verwendet, die von Browsern automatisch vor der eigentlichen Anfrage gesendet wird, wenn es darum geht, festzustellen, ob die Anfrage aus Sicht der CORS-Richtlinie (Cross-Origin Resource Sharing) zulässig ist. Wenn Sie diese Methode zulassen, aber keine angemessene Antwort implementieren, kann dies zu Inkonsistenzen und potenziellen Sicherheitsproblemen führen.


Weitere Lektüre .[#toc-further-reading]
=======================================

- [Methoden und Attribute einfügen |best-practices:inject-method-attribute]
- [Zusammenstellen von Presentern aus Traits |best-practices:presenter-traits]
- [Übergabe von Einstellungen an Presenter |best-practices:passing-settings-to-presenters]
- [Wie man zu einer früheren Seite zurückkehrt |best-practices:restore-request]

Vortragende

Wir werden lernen, wie man Presenter und Vorlagen in Nette schreibt. Nach der Lektüre werden Sie wissen:

  • wie der Presenter funktioniert
  • was persistente Parameter sind
  • wie man eine Vorlage rendert

Wir wissen bereits, dass ein Presenter eine Klasse ist, die eine bestimmte Seite einer Webanwendung darstellt, z. B. eine Homepage, ein Produkt im E-Shop, ein Anmeldeformular, ein Sitemap-Feed usw. Die Anwendung kann von einem bis zu Tausenden von Presentern haben. In anderen Frameworks werden sie auch als Controller bezeichnet.

Normalerweise bezieht sich der Begriff Presenter auf einen Abkömmling der Klasse Nette\Application\UI\Presenter, die für Web-Interfaces geeignet ist und die wir im weiteren Verlauf dieses Kapitels besprechen werden. Im allgemeinen Sinne ist ein Presenter jedes Objekt, das die Schnittstelle Nette\Application\IPresenter implementiert.

Lebenszyklus eines Presenters

Die Aufgabe des Presenters besteht darin, die Anfrage zu verarbeiten und eine Antwort zu liefern (die eine HTML-Seite, ein Bild, eine Routing usw. sein kann).

Am Anfang steht also eine Anfrage. Dabei handelt es sich nicht direkt um eine HTTP-Anfrage, sondern um ein Nette\Application\Request -Objekt, in das die HTTP-Anfrage mithilfe eines Routers umgewandelt wurde. Mit diesem Objekt kommen wir in der Regel nicht in Berührung, da der Präsentator die Verarbeitung der Anfrage geschickt an spezielle Methoden delegiert, die wir jetzt sehen werden.

Lebenszyklus des Presenters

Die Abbildung zeigt eine Liste von Methoden, die nacheinander von oben nach unten aufgerufen werden, sofern sie existieren. Keine von ihnen muss existieren, wir können einen völlig leeren Presenter ohne eine einzige Methode haben und ein einfaches statisches Web darauf aufbauen.

__construct()

Der Konstruktor gehört nicht direkt zum Lebenszyklus des Präsentators, da er zum Zeitpunkt der Erstellung des Objekts aufgerufen wird. Aber wir erwähnen ihn wegen seiner Bedeutung. Der Konstruktor (zusammen mit der Methode inject) wird verwendet, um Abhängigkeiten zu übergeben.

Der Presenter sollte sich nicht um die Geschäftslogik der Anwendung kümmern, nicht in die Datenbank schreiben und aus ihr lesen, keine Berechnungen durchführen, usw. Dies ist die Aufgabe für Klassen aus einer Schicht, die wir Modell nennen. Zum Beispiel kann die Klasse ArticleRepository für das Laden und Speichern von Artikeln zuständig sein. Damit der Presenter sie verwenden kann, wird sie mittels Dependency Injection übergeben:

class ArticlePresenter extends Nette\Application\UI\Presenter
{
	public function __construct(
		private ArticleRepository $articles,
	) {
	}
}

startup()

Unmittelbar nach Erhalt der Anfrage wird die Methode startup () aufgerufen. Sie können sie verwenden, um Eigenschaften zu initialisieren, Benutzerrechte zu prüfen, usw. Es ist erforderlich, immer den Vorgänger parent::startup() aufzurufen.

action<Action>(args...)

Ähnlich wie bei der Methode render<View>(). Während render<View>() dazu gedacht ist, Daten für eine bestimmte Vorlage vorzubereiten, die anschließend gerendert wird, wird in action<Action>() wird eine Anfrage ohne anschließendes Rendering der Vorlage verarbeitet. So werden z. B. Daten verarbeitet, ein Benutzer an- oder abgemeldet usw., und dann wird er an eine andere Stelle weitergeleitet.

Es ist wichtig, dass action<Action>() vor aufgerufen wird render<View>()aufgerufen wird, damit wir darin möglicherweise den weiteren Verlauf des Lebenszyklus ändern können, d. h. die Vorlage, die gerendert wird, und auch die Methode render<View>() die aufgerufen wird, mit setView('otherView').

Die Parameter der Anfrage werden an die Methode übergeben. Es ist möglich und empfehlenswert, Typen für die Parameter anzugeben, z. B. actionShow(int $id, ?string $slug = null) – wenn der Parameter id fehlt oder keine ganze Zahl ist, gibt der Präsentator den Fehler 404 zurück und bricht die Operation ab.

handle<Signal>(args...)

Diese Methode verarbeitet die sogenannten Signale, die wir im Kapitel über Komponenten besprechen werden. Sie ist hauptsächlich für Komponenten und die Verarbeitung von AJAX-Anfragen gedacht.

Die Parameter werden an die Methode übergeben, wie im Fall von action<Action>()übergeben, einschließlich der Typüberprüfung.

beforeRender()

Die Methode beforeRender wird, wie der Name schon sagt, vor jeder Methode aufgerufen render<View>(). Sie wird für die allgemeine Konfiguration von Vorlagen, die Übergabe von Variablen für das Layout und so weiter verwendet.

render<View>(args...)

Der Ort, an dem wir die Vorlage für das spätere Rendering vorbereiten, Daten an sie übergeben usw.

Die Parameter werden an die Methode übergeben, wie im Fall von action<Action>()übergeben, einschließlich der Typüberprüfung.

public function renderShow(int $id): void
{
	// wir beziehen Daten aus dem Modell und übergeben sie an die Vorlage
	$this->template->article = $this->articles->getById($id);
}

afterRender()

Die Methode afterRender wird, wie der Name schon sagt, nach jeder render<View>() Methode aufgerufen. Sie wird eher selten verwendet.

shutdown()

Sie wird am Ende des Lebenszyklus des Präsentators aufgerufen.

Guter Rat, bevor wir weitermachen. Wie Sie sehen können, kann der Präsentator mehr Aktionen/Ansichten verarbeiten, d.h. mehr Methoden haben render<View>(). Wir empfehlen jedoch, Presenter mit einer oder so wenigen Aktionen wie möglich zu entwerfen.

Senden einer Antwort

Die Antwort des Präsentators ist in der Regel das Rendern der Vorlage mit der HTML-Seite, aber es kann auch das Senden einer Datei, JSON oder sogar die Routing zu einer anderen Seite sein.

Zu jedem Zeitpunkt des Lebenszyklus können Sie eine der folgenden Methoden verwenden, um eine Antwort zu senden und gleichzeitig den Präsentator zu beenden:

Wenn Sie keine dieser Methoden aufrufen, fährt der Presenter automatisch mit dem Rendern der Vorlage fort. Und warum? Nun, weil wir in 99% der Fälle eine Vorlage zeichnen wollen, also nimmt der Präsentator dieses Verhalten als Standard an und will uns die Arbeit erleichtern.

Presenter hat eine Methode link(), die verwendet wird, um URL-Links zu anderen Presentern zu erstellen. Der erste Parameter ist der Zielmoderator und die Aktion, gefolgt von den Argumenten, die als Array übergeben werden können:

$url = $this->link('Product:show', $id);

$url = $this->link('Product:show', [$id, 'lang' => 'en']);

In der Vorlage erstellen wir Links zu anderen Präsentatoren und Aktionen wie folgt:

<a n:href="Product:show $id">product detail</a>

Schreiben Sie einfach das bekannte Paar Presenter:action anstelle der echten URL und fügen Sie beliebige Parameter ein. Der Trick ist n:href, das besagt, dass dieses Attribut von Latte verarbeitet wird und eine echte URL erzeugt. In Nette müssen Sie überhaupt nicht über URLs nachdenken, sondern nur über Presenter und Aktionen.

Weitere Informationen finden Sie unter Links erstellen.

Umleitung

Die Methoden redirect() und forward() werden verwendet, um zu einem anderen Präsentator zu springen. Sie haben eine sehr ähnliche Syntax wie die Methode link().

Die forward() schaltet ohne HTTP-Umleitung sofort auf den neuen Präsentator um:

$this->forward('Product:show');

Beispiel für eine so genannte temporäre Umleitung mit HTTP-Code 302 (oder 303, wenn die aktuelle Anfragemethode POST ist):

$this->redirect('Product:show', $id);

Um eine dauerhafte Umleitung mit HTTP-Code 301 zu erreichen, verwenden Sie:

$this->redirectPermanent('Product:show', $id);

Sie können mit der Methode redirectUrl() zu einer anderen URL außerhalb der Anwendung umleiten. Der HTTP-Code kann als zweiter Parameter angegeben werden, wobei der Standardwert 302 ist (oder 303, wenn die aktuelle Anforderungsmethode POST ist):

$this->redirectUrl('https://nette.org');

Die Umleitung beendet sofort den Lebenszyklus des Präsentators, indem sie die sogenannte Silent Termination Exception Nette\Application\AbortException auslöst.

Vor der Routing ist es möglich, eine Flash-Nachricht zu senden, die nach der Routing in der Vorlage angezeigt wird.

Flash-Nachrichten

Dies sind Meldungen, die in der Regel über das Ergebnis eines Vorgangs informieren. Ein wichtiges Merkmal von Flash-Meldungen ist, dass sie auch nach einer Routing in der Vorlage verfügbar sind. Selbst nachdem sie angezeigt wurden, bleiben sie noch 30 Sekunden lang erhalten – zum Beispiel für den Fall, dass der Benutzer die Seite unbeabsichtigt aktualisiert – die Nachricht geht nicht verloren.

Rufen Sie einfach die Methode flashMessage() auf und Presenter kümmert sich um die Übergabe der Nachricht an die Vorlage. Das erste Argument ist der Text der Nachricht und das zweite optionale Argument ist ihr Typ (Fehler, Warnung, Info usw.). Die Methode flashMessage() gibt eine Instanz von flash message zurück, damit wir weitere Informationen hinzufügen können.

$this->flashMessage('Item was removed.');
$this->redirect(/* ... */);

In der Vorlage sind diese Meldungen in der Variablen $flashes als Objekte stdClass verfügbar, die die Eigenschaften message (Meldungstext) und type (Meldungstyp) enthalten und die bereits erwähnten Benutzerinformationen enthalten können. Wir zeichnen sie wie folgt:

{foreach $flashes as $flash}
	<div class="flash {$flash->type}">{$flash->message}</div>
{/foreach}

Fehler 404 usw.

Wenn wir die Anfrage nicht erfüllen können, weil z.B. der Artikel, den wir anzeigen wollen, nicht in der Datenbank existiert, werden wir den Fehler 404 mit der Methode error(?string $message = null, int $httpCode = 404) ausgeben, die den HTTP-Fehler 404 darstellt:

public function renderShow(int $id): void
{
	$article = $this->articles->getById($id);
	if (!$article) {
		$this->error();
	}
	// ...
}

Der HTTP-Fehlercode kann als zweiter Parameter übergeben werden, der Standardwert ist 404. Die Methode funktioniert, indem sie die Ausnahme Nette\Application\BadRequestException auslöst, woraufhin Application die Kontrolle an den Fehler-Moderator weitergibt. Dabei handelt es sich um einen Presenter, dessen Aufgabe es ist, eine Seite anzuzeigen, die über den Fehler informiert. Der Fehler-Presenter wird in der Anwendungskonfiguration festgelegt.

Senden von JSON

Beispiel für eine Action-Methode, die Daten im JSON-Format sendet und den Präsentator verlässt:

public function actionData(): void
{
	$data = ['hello' => 'nette'];
	$this->sendJson($data);
}

Parameter anfordern

Der Präsentator, wie auch jede Komponente, bezieht seine Parameter aus der HTTP-Anfrage. Ihre Werte können mit der Methode getParameter($name) oder getParameters() abgerufen werden. Bei den Werten handelt es sich um Strings oder Arrays von Strings, also im Wesentlichen um Rohdaten, die direkt aus der URL bezogen werden.

Für zusätzlichen Komfort empfiehlt es sich, die Parameter über Eigenschaften zugänglich zu machen. Beschriften Sie sie einfach mit dem #[Parameter] Attribut:

use Nette\Application\Attributes\Parameter;  // diese Zeile ist wichtig

class HomePresenter extends Nette\Application\UI\Presenter
{
	#[Parameter]
	public string $theme; // muss öffentlich sein
}

Für Eigenschaften empfehlen wir die Angabe des Datentyps (z. B. string). Nette wird den Wert dann automatisch auf der Grundlage dieses Typs umwandeln. Parameterwerte können auch validiert werden.

Beim Erstellen einer Verknüpfung können Sie den Wert für die Parameter direkt festlegen:

<a n:href="Home:default theme: dark">click</a>

Dauerhafte Parameter

Persistente Parameter werden verwendet, um den Zustand zwischen verschiedenen Anfragen zu erhalten. Ihr Wert bleibt gleich, auch wenn ein Link angeklickt wird. Im Gegensatz zu Sitzungsdaten werden sie in der URL übergeben. Dies geschieht völlig automatisch, so dass es nicht notwendig ist, sie in link() oder n:href explizit anzugeben.

Beispiel für die Verwendung? Sie haben eine mehrsprachige Anwendung. Die aktuelle Sprache ist ein Parameter, der immer Teil der URL sein muss. Es wäre aber unglaublich mühsam, ihn in jeden Link aufzunehmen. Also machen Sie ihn zu einem dauerhaften Parameter mit dem Namen lang und er wird sich selbst tragen. Toll!

Das Erstellen eines dauerhaften Parameters ist in Nette extrem einfach. Erstellen Sie einfach eine öffentliche Eigenschaft und kennzeichnen Sie sie mit dem Attribut: (früher wurde /** @persistent */ verwendet)

use Nette\Application\Attributes\Persistent; // diese Zeile ist wichtig

class ProductPresenter extends Nette\Application\UI\Presenter
{
	#[Persistent]
	public string $lang; // muss öffentlich sein
}

Wenn $this->lang einen Wert wie 'en' hat, dann werden Links, die mit link() oder n:href erstellt werden, auch den Parameter lang=en enthalten. Und wenn der Link angeklickt wird, wird er wieder $this->lang = 'en' sein.

Für Eigenschaften wird empfohlen, den Datentyp anzugeben (z. B. string), und Sie können auch einen Standardwert angeben. Parameterwerte können validiert werden.

Persistente Parameter werden standardmäßig zwischen allen Aktionen eines bestimmten Präsentators weitergegeben. Um sie zwischen mehreren Präsentatoren zu übergeben, müssen Sie sie entweder definieren:

  • in einem gemeinsamen Vorfahren, von dem die Präsentatoren erben
  • in der Eigenschaft, die die Präsentatoren verwenden:
trait LanguageAware
{
	#[Persistent]
	public string $lang;
}

class ProductPresenter extends Nette\Application\UI\Presenter
{
	use LanguageAware;
}

Sie können den Wert eines dauerhaften Parameters ändern, wenn Sie einen Link erstellen:

<a n:href="Product:show $id, lang: cs">detail in Czech</a>

Oder er kann zurückgesetzt werden, d.h. aus der URL entfernt werden. Er nimmt dann seinen Standardwert an:

<a n:href="Product:show $id, lang: null">click</a>

Interaktive Komponenten

Presenter haben ein eingebautes Komponentensystem. Komponenten sind separate, wiederverwendbare Einheiten, die wir in Presenter einfügen. Es kann sich dabei um Formulare, Datenfelder, Menüs und alles handeln, was für eine wiederholte Verwendung sinnvoll ist.

Wie werden Komponenten im Presenter platziert und anschließend verwendet? Das wird im Kapitel Komponenten erklärt. Sie werden sogar erfahren, was sie mit Hollywood zu tun haben.

Wo kann ich einige Komponenten bekommen? Auf der Seite Componette finden Sie einige Open-Source-Komponenten und andere Erweiterungen für Nette, die von der Nette-Framework-Gemeinschaft erstellt und geteilt werden.

Tiefer gehen

Was wir bisher in diesem Kapitel gezeigt haben, wird wahrscheinlich ausreichen. Die folgenden Zeilen sind für diejenigen gedacht, die sich eingehend mit Moderatoren beschäftigen und alles wissen wollen.

Validierung von Parametern

Die Werte von Anfrageparametern und dauerhaften Parametern, die von URLs empfangen werden, werden von der Methode loadState() in Eigenschaften geschrieben. Sie prüft auch, ob der in der Eigenschaft angegebene Datentyp übereinstimmt, andernfalls antwortet sie mit einem 404-Fehler und die Seite wird nicht angezeigt.

Verlassen Sie sich niemals blind auf Parameter, da sie leicht vom Benutzer in der URL überschrieben werden können. So überprüfen wir zum Beispiel, ob $this->lang zu den unterstützten Sprachen gehört. Eine gute Möglichkeit, dies zu tun, besteht darin, die oben erwähnte Methode loadState() zu überschreiben:

class ProductPresenter extends Nette\Application\UI\Presenter
{
	#[Persistent]
	public string $lang;

	public function loadState(array $params): void
	{
		parent::loadState($params); // hier wird die $this->lang gesetzt
		// nach der Prüfung der Benutzerwerte:
		if (!in_array($this->lang, ['en', 'cs'])) {
			$this->error();
		}
	}
}

Speichern und Wiederherstellen der Anfrage

Die Anfrage, die der Präsentator bearbeitet, ist ein Objekt Nette\Application\Request und wird von der Methode getRequest() des Präsentators zurückgegeben.

Sie können die aktuelle Anfrage in einer Sitzung speichern oder sie aus der Sitzung wiederherstellen und den Präsentator sie erneut ausführen lassen. Dies ist z. B. nützlich, wenn ein Benutzer ein Formular ausfüllt und sein Login abläuft. Um keine Daten zu verlieren, speichern wir vor der Weiterleitung zur Anmeldeseite die aktuelle Anfrage in der Sitzung mit $reqId = $this->storeRequest(), die einen Bezeichner in Form eines kurzen Strings zurückgibt und diesen als Parameter an den Anmeldepräsentator übergibt.

Nach der Anmeldung rufen wir die Methode $this->restoreRequest($reqId) auf, die die Anfrage aus der Session abholt und an diese weiterleitet. Die Methode prüft, ob die Anfrage von demselben Benutzer erstellt wurde, der jetzt angemeldet ist. Wenn sich ein anderer Benutzer anmeldet oder der Schlüssel ungültig ist, tut sie nichts und das Programm läuft weiter.

Siehe das Kochbuch How to return to a earlier page.

Kanonisierung

Presenter haben eine wirklich großartige Funktion, die SEO (Optimierung der Auffindbarkeit im Internet) verbessert. Sie verhindern automatisch das Vorhandensein von doppeltem Inhalt unter verschiedenen URLs. Wenn mehrere URLs zu einem bestimmten Ziel führen, z. B. /index und /index?page=1, bestimmt das Framework eine von ihnen als die primäre (kanonische) und leitet die anderen mit dem HTTP-Code 301 auf diese um. Auf diese Weise werden die Seiten von den Suchmaschinen nicht doppelt indiziert und ihr Page Rank nicht geschwächt.

Dieser Vorgang wird als Kanonisierung bezeichnet. Die kanonische URL ist die vom Router generierte URL, in der Regel die erste geeignete Route in der Sammlung.

Die Kanonisierung ist standardmäßig aktiviert und kann über $this->autoCanonicalize = false ausgeschaltet werden.

Eine Umleitung findet bei einer AJAX- oder POST-Anfrage nicht statt, da dies zu Datenverlust oder keinem SEO-Mehrwert führen würde.

Sie können die Kanonisierung auch manuell mit der Methode canonicalize() aufrufen, die wie die Methode link() den Präsentator, Aktionen und Parameter als Argumente erhält. Sie erstellt einen Link und vergleicht ihn mit der aktuellen URL. Wenn sie sich unterscheidet, wird sie auf den erzeugten Link umgeleitet.

public function actionShow(int $id, ?string $slug = null): void
{
	$realSlug = $this->facade->getSlugForId($id);
	// leitet um, wenn $slug nicht mit $realSlug übereinstimmt
	$this->canonicalize('Product:show', [$id, $realSlug]);
}

Ereignisse

Zusätzlich zu den Methoden startup(), beforeRender() und shutdown(), die im Rahmen des Lebenszyklus des Presenters aufgerufen werden, können weitere Funktionen definiert werden, die automatisch aufgerufen werden. Der Präsentator definiert die sogenannten Ereignisse, und Sie fügen deren Handler zu den Arrays $onStartup, $onRender und $onShutdown hinzu.

class ArticlePresenter extends Nette\Application\UI\Presenter
{
	public function __construct()
	{
		$this->onStartup[] = function () {
			// ...
		};
	}
}

Die Handler im Array $onStartup werden kurz vor der Methode startup() aufgerufen, dann $onRender zwischen beforeRender() und render<View>() und schließlich $onShutdown kurz vor shutdown().

Antworten

Die vom Präsentator zurückgegebene Antwort ist ein Objekt, das die Schnittstelle Nette\Application\Response implementiert. Es gibt eine Reihe von vorgefertigten Antworten:

Antworten werden mit der Methode sendResponse() gesendet:

use Nette\Application\Responses;

// Klartext
$this->sendResponse(new Responses\TextResponse('Hello Nette!'));

// Sendet eine Datei
$this->sendResponse(new Responses\FileResponse(__DIR__ . '/invoice.pdf', 'Invoice13.pdf'));

// Sendet einen Rückruf
$callback = function (Nette\Http\IRequest $httpRequest, Nette\Http\IResponse $httpResponse) {
	if ($httpResponse->getHeader('Content-Type') === 'text/html') {
		echo '<h1>Hallo</h1>';
	}
};
$this->sendResponse(new Responses\CallbackResponse($callback));

Zugangsbeschränkung mit #[Requires]

Das Attribut #[Requires] Attribut bietet erweiterte Optionen zur Einschränkung des Zugriffs auf Präsentatoren und ihre Methoden. Es kann verwendet werden, um HTTP-Methoden zu spezifizieren, AJAX-Anfragen zu verlangen, den Zugriff auf denselben Ursprung zu beschränken und den Zugriff nur auf Weiterleitungen zu beschränken. Das Attribut kann sowohl auf Presenter-Klassen als auch auf einzelne Methoden angewendet werden, z. B. action<Action>(), render<View>(), handle<Signal>(), und createComponent<Name>().

Sie können diese Einschränkungen angeben:

  • auf HTTP-Methoden: #[Requires(methods: ['GET', 'POST'])]
  • die eine AJAX-Anfrage erfordern: #[Requires(ajax: true)]
  • Zugriff nur vom selben Ursprung: #[Requires(sameOrigin: true)]
  • Zugriff nur über Weiterleitung: #[Requires(forward: true)]
  • Einschränkungen für bestimmte Aktionen: #[Requires(actions: 'default')]

Für Einzelheiten siehe Verwendung des Requires Attributs.

HTTP-Methodenprüfung

In Nette überprüfen die Moderatoren die HTTP-Methode jeder eingehenden Anfrage automatisch, hauptsächlich aus Sicherheitsgründen. Standardmäßig sind die Methoden GET, POST, HEAD, PUT, DELETE, PATCH zugelassen.

Wenn Sie zusätzliche Methoden wie OPTIONS aktivieren möchten, können Sie das #[Requires] Attribut verwenden (ab Nette Application v3.2):

#[Requires(methods: ['GET', 'POST', 'HEAD', 'PUT', 'DELETE', 'PATCH', 'OPTIONS'])]
class MyPresenter extends Nette\Application\UI\Presenter
{
}

In Version 3.1 wird die Überprüfung in checkHttpMethod() durchgeführt, das prüft, ob die in der Anfrage angegebene Methode im Array $presenter->allowedMethods enthalten ist. Fügen Sie eine Methode wie diese hinzu:

class MyPresenter extends Nette\Application\UI\Presenter
{
    protected function checkHttpMethod(): void
    {
        $this->allowedMethods[] = 'OPTIONS';
        parent::checkHttpMethod();
    }
}

Es ist wichtig zu betonen, dass, wenn Sie die OPTIONS -Methode zulassen, Sie sie auch in Ihrem Präsentator richtig behandeln müssen. Diese Methode wird häufig als so genannte Preflight-Anfrage verwendet, die von Browsern automatisch vor der eigentlichen Anfrage gesendet wird, wenn es darum geht, festzustellen, ob die Anfrage aus Sicht der CORS-Richtlinie (Cross-Origin Resource Sharing) zulässig ist. Wenn Sie diese Methode zulassen, aber keine angemessene Antwort implementieren, kann dies zu Inkonsistenzen und potenziellen Sicherheitsproblemen führen.

Weitere Lektüre