In Laravel versuche ich, $input = Request::all();
mit einer store()
-Methode in meinem Controller aufzurufen, erhalte jedoch die folgende Fehlermeldung:
Die nicht statische Methode
Illuminate\Http\Request::all()
sollte nicht statisch aufgerufen werden, wenn$this
aus einem inkompatiblen Kontext angenommen wird
Irgendwelche Hilfe, um den besten Weg zu finden, dies zu korrigieren? (Ich folge einem Laracast)
Die Fehlermeldung ist darauf zurückzuführen, dass der Anruf nicht durch die Request
-Fassade geht.
Veränderung
use Illuminate\Http\Request;
Zu
use Request;
und es sollte anfangen zu arbeiten.
In der Datei config/app.php finden Sie eine Liste der Klassenaliase. Dort sehen Sie, dass die Basisklasse Request
auf die Illuminate\Support\Facades\Request
-Klasse einen Aliasing vorgenommen hat. Aus diesem Grund müssen Sie zur Verwendung der Request
-Fassade in einer Datei mit Namensbereich angeben, dass die Basisklasse verwendet werden soll: use Request;
.
Da diese Frage ein wenig Verkehr bekommt, wollte ich die Antwort ein wenig aktualisieren, seit Laravel 5 offiziell veröffentlicht wurde.
Während das oben Genannte technisch immer noch korrekt ist und funktionieren wird, ist die use Illuminate\Http\Request;
-Anweisung in der neuen Controller-Vorlage enthalten, um den Entwicklern zu helfen, Abhängigkeiten in Abhängigkeit von der Fassade zu verwenden.
Beim Einfügen des Request-Objekts in den Konstruktor (oder Methoden, wie in Laravel 5 verfügbar), sollte das Illuminate\Http\Request
-Objekt eingefügt werden, und nicht die Request
-Fassade.
Anstatt die Controller-Vorlage so zu ändern, dass sie mit der Request-Fassade arbeitet, empfiehlt es sich, mit der angegebenen Controller-Vorlage zu arbeiten und die Abhängigkeitsinjektion zu nutzen (über Konstruktor oder Methoden).
Beispiel über Methode
<?php namespace App\Http\Controllers;
use App\Http\Controllers\Controller;
use Illuminate\Http\Request;
class UserController extends Controller {
/**
* Store a newly created resource in storage.
*
* @param Illuminate\Http\Request $request
* @return Response
*/
public function store(Request $request) {
$name = $request->input('name');
}
}
Beispiel via Konstruktor
<?php namespace App\Http\Controllers;
use App\Http\Controllers\Controller;
use Illuminate\Http\Request;
class UserController extends Controller {
protected $request;
public function __construct(Request $request) {
$this->request = $request;
}
/**
* Store a newly created resource in storage.
*
* @return Response
*/
public function store() {
$name = $this->request->input('name');
}
}
Injizieren Sie das Anforderungsobjekt mithilfe der magischen Injektion von Laravel in den Controller und greifen Sie dann auf die Funktion nicht statisch zu. Laravel fügt automatisch autonome Klassen konkrete Abhängigkeiten hinzu
class MyController()
{
protected $request;
public function __construct(\Illuminate\Http\Request $request)
{
$this->request = $request;
}
public function myFunc()
{
$input = $this->request->all();
}
}
Die Fassade ist eine weitere Anforderungsklasse, mit dem vollständigen Pfad darauf zugreifen:
$input = \Request::all();
verwenden Sie stattdessen den Helper request()
. Sie müssen sich keine Gedanken über use
-Anweisungen machen, und diese Art von Problem tritt daher nicht wieder auf.
$input = request()->all();
einfach
use Illuminate\Http\Request;
public function store(Request $request){
dd($request->all());
}
ist im Kontext dasselbe zu sagen
use Request;
public function store(){
dd(Request::all());
}
Ich dachte, es wäre nützlich für zukünftige Besucher, eine kurze Erklärung zu geben, was hier vor sich geht.
Illuminate\Http\Request
Laravels Klasse Illuminate\Http\Request
Hat eine Methode mit dem Namen all
(tatsächlich ist die Methode all
in einem Merkmal definiert, das die Klasse Request
verwendet, genannt Illuminate\Http\Concerns\InteractsWithInput
). Die Signatur der all
-Methode sieht zum Zeitpunkt des Schreibens folgendermaßen aus:
public function all($keys = null)
Diese Methode ist nicht als static
definiert. Wenn Sie also versuchen, die Methode in einem statischen Kontext aufzurufen, d. H. Illuminate\Http\Request::all()
, wird der Fehler in der Frage von OP angezeigt. Die all
-Methode ist eine Instanzmethode und verarbeitet Informationen, die in einer Instanz der Request
-Klasse vorhanden sind. Daher macht es keinen Sinn, sie auf diese Weise aufzurufen.
Eine Fassade in Laravel bietet Entwicklern eine bequeme Möglichkeit, auf Objekte im IoC-Container zuzugreifen und Methoden für diese Objekte aufzurufen. Ein Entwickler kann eine Methode auf einer Fassade wie Request::all()
, aber der eigentliche Methodenaufruf für das echte Illuminate\Http\Request
Objekt ist nicht statisch.
Eine Fassade funktioniert wie ein Proxy - sie verweist auf ein Objekt im IoC-Container und leitet den statischen Methodenaufruf an dieses Objekt weiter (nicht statisch). Nehmen wir zum Beispiel die Fassade Illuminate\Support\Facades\Request
, So sieht es aus:
class Request extends Facade
{
protected static function getFacadeAccessor()
{
return 'request';
}
}
Unter der Haube verwendet die Basisklasse Illuminate\Support\Facades\Facade
Eine PHP= magic, nämlich die __callStatic
-Methode, um:
all
ohne ParametergetFacadeAccessor
zurückgegebenen Schlüssel, in diesem Fall ein Illuminate\Http\Request
- Objektall
für eine Instanz von Illuminate\Http\Request
Nicht statisch aufgerufen.Aus diesem Grund ist, wie @patricus in seiner Antwort oben ausgeführt hat, der Fehler nicht mehr vorhanden, wenn die Anweisung use
/import so geändert wird, dass sie sich auf die Fassade bezieht, da PHP ist besorgt, all
wurde korrekt für eine Instanz von Illuminate\Http\Request
aufgerufen.
Aliasing ist eine weitere Funktion, die Laravel zur Vereinfachung dient. Sie erstellt effektiv Alias-Klassen, die auf Fassaden im Root-Namespace verweisen. Wenn Sie sich Ihre config/app.php
- Datei ansehen, Unter der Taste aliases
finden Sie eine lange Liste von Zuordnungen von Zeichenfolgen zu Fassadenklassen.
'aliases' => [
'App' => Illuminate\Support\Facades\App::class,
'Artisan' => Illuminate\Support\Facades\Artisan::class,
'Auth' => Illuminate\Support\Facades\Auth::class,
// ...
'Request' => Illuminate\Support\Facades\Request::class,
Laravel erstellt diese Aliasklassen für Sie, basierend auf Ihrer Konfiguration. Auf diese Weise können Sie Klassen verwenden, die im Root-Namespace verfügbar sind (wie in den String-Schlüsseln der aliases
-Konfiguration angegeben), als würden Sie die Fassade verwenden selbst:
use Request:
class YourController extends Controller
{
public function yourMethod()
{
$input = Request::all();
// ...
}
}
Während in Laravel noch Fassaden und Aliasing bereitgestellt werden, ist es möglich und in der Regel empfehlenswert, die Abhängigkeitsinjektionsroute einzuschlagen. Verwenden Sie beispielsweise die Konstruktorinjektion, um dasselbe Ergebnis zu erzielen:
use Illuminate\Http\Request;
class YourController extends Controller
{
protected $request;
public function __construct(Request $request)
{
$this->request = $request;
}
public function yourMethod()
{
$input = $this->request->all();
// ...
}
}
Dieser Ansatz hat eine Reihe von Vorteilen, aber meiner Meinung nach ist der größte Vorteil bei der Abhängigkeitsinjektion, dass er das Testen Ihres Codes erleichtert. Indem Sie die Abhängigkeiten Ihrer Klassen als Konstruktor- oder Methodenargumente deklarieren, ist es sehr einfach, diese Abhängigkeiten auszublenden und Ihre Klasse isoliert zu testen.
Dieses Problem wurde sogar mit der use Illuminate\Http\Request;
-Zeile an der Oberseite meines Controllers angegangen. Ich musste an meinen Haaren ziehen, bis mir klar wurde, dass ich $request::ip()
statt $request->ip()
machte. Kann dir passieren, wenn du die ganze Nacht nicht geschlafen hast und den Code um 6 Uhr morgens mit halb geöffneten Augen betrachtest.
Hoffe, das hilft jemandem die Straße runter.
ich mache es mit einer Scope-Definition
public function pagar (\ Illuminate\Http\Request $ request) {//