Dans Laravel, j'essaie d'appeler $input = Request::all();
sur une méthode store()
dans mon contrôleur, mais l'erreur suivante s'affiche:
La méthode non statique
Illuminate\Http\Request::all()
ne doit pas être appelée de manière statique, en supposant que$this
est issu d'un contexte incompatible.
Toute aide pour déterminer le meilleur moyen de corriger cela? (Je suis un Laracast)
Le message d'erreur est dû au fait que l'appel ne passe pas par la façade Request
.
Changement
use Illuminate\Http\Request;
À
use Request;
et il devrait commencer à fonctionner.
Dans le fichier config/app.php, vous pouvez trouver une liste des alias de classe. Vous y verrez que la classe de base Request
a été associée à la classe Illuminate\Support\Facades\Request
. De ce fait, pour utiliser la façade Request
dans un fichier à espace de noms, vous devez spécifier l'utilisation de la classe de base: use Request;
.
Étant donné que cette question semble générer un peu de trafic, je voulais mettre à jour la réponse un peu depuis la sortie officielle de Laravel 5.
Bien que ce qui précède soit encore techniquement correct et fonctionne, l’instruction use Illuminate\Http\Request;
est incluse dans le nouveau modèle de contrôleur afin d’aider les développeurs à choisir entre l’injection de dépendances et la façade.
Lors de l'injection de l'objet Request dans le constructeur (ou dans les méthodes disponibles dans Laravel 5), c'est l'objet Illuminate\Http\Request
qui doit être injecté et non la façade Request
.
Ainsi, au lieu de modifier le modèle de contrôleur pour qu'il fonctionne avec la façade de demande, il est recommandé de travailler avec le modèle de contrôleur donné et de passer à l'injection de dépendance (via un constructeur ou des méthodes).
Exemple via la méthode
<?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');
}
}
Exemple via le constructeur
<?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');
}
}
Injectez l'objet de requête dans le contrôleur à l'aide de l'injection magique de Laravel, puis accédez à la fonction de manière non statique. Laravel va automatiquement injecter des dépendances concrètes dans les classes autoloadées
class MyController()
{
protected $request;
public function __construct(\Illuminate\Http\Request $request)
{
$this->request = $request;
}
public function myFunc()
{
$input = $this->request->all();
}
}
La façade est une autre classe de requête, accédez-y avec le chemin complet:
$input = \Request::all();
utilisez plutôt l'assistant request()
. Vous n'avez pas à vous soucier des déclarations use
et ces problèmes ne se reproduiront plus.
$input = request()->all();
simple
use Illuminate\Http\Request;
public function store(Request $request){
dd($request->all());
}
est le même dans le contexte en disant
use Request;
public function store(){
dd(Request::all());
}
Je faisais face à ce problème même avec la ligne use Illuminate\Http\Request;
en haut de mon contrôleur. Je me suis tiré les cheveux jusqu'à ce que je réalise que je faisais $request::ip()
au lieu de $request->ip()
. Cela peut vous arriver si vous n’avez pas dormi toute la nuit et que vous regardez le code à 6 heures du matin avec les yeux mi-ouverts.
J'espère que cela aide quelqu'un sur la route.
J’ai pensé qu’il serait utile que les futurs visiteurs expliquent un peu ce qui se passe ici.
Illuminate\Http\Request
La classe Illuminate\Http\Request
de Laravel a une méthode nommée all
(en fait, la méthode all
est définie dans un trait que la classe Request
utilise, appelé Illuminate\Http\Concerns\InteractsWithInput
). La signature de la méthode all
au moment de l'écriture ressemble à ceci:
public function all($keys = null)
Cette méthode n'est pas définie en tant que static
. Ainsi, lorsque vous essayez d'appeler la méthode dans un contexte statique, c'est-à-dire Illuminate\Http\Request::all()
, vous obtenez le message d'erreur affiché dans la question de OP. La méthode all
est une méthode d'instance et traite les informations présentes dans une instance de la classe Request
; l'appel de cette manière n'a donc aucun sens.
Une façade dans Laravel fournit aux développeurs un moyen pratique d'accéder aux objets du conteneur IoC et d'appeler des méthodes sur ces objets. Un développeur peut appeler une méthode "de manière statique" sur une façade telle que Request::all()
, mais l'appel de méthode réel sur l'objet realIlluminate\Http\Request
est not static.
Une façade fonctionne comme un proxy: elle fait référence à un objet du conteneur IoC et transmet l'appel de méthode statique à cet objet (de manière non statique). Par exemple, prenons la façade Illuminate\Support\Facades\Request
, voici à quoi elle ressemble:
class Request extends Facade
{
protected static function getFacadeAccessor()
{
return 'request';
}
}
Sous le capot, la classe Illuminate\Support\Facades\Facade
de base utilise une magie PHP, à savoir la méthode __callStatic
pour:
all
sans paramètregetFacadeAccessor
, dans ce cas, un objet Illuminate\Http\Request
all
est appelé de manière non statique sur une instance de Illuminate\Http\Request
.C'est pourquoi, comme @patricus l'a souligné dans sa réponse ci-dessus, en changeant l'instruction use
/import pour faire référence à la façade, l'erreur n'est plus là car, pour ce qui concerne PHP, all
a été correctement appelé sur une instance de Illuminate\Http\Request
.
Le crénelage est une autre caractéristique fournie par Laravel pour plus de commodité. Cela fonctionne en créant efficacement des classes d'alias qui pointent vers des façades dans l'espace de noms racine. Si vous examinez votre fichier config/app.php
, sous la clé aliases
, vous trouverez une longue liste de mappages de chaînes sur des classes de façade. Par exemple:
'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 crée ces classes d'alias pour vous, en fonction de votre configuration, ce qui vous permet d'utiliser les classes disponibles dans l'espace de noms racine (comme indiqué par les clés de chaîne de la configuration aliases
) comme si vous utilisiez la façade elle-même:
use Request:
class YourController extends Controller
{
public function yourMethod()
{
$input = Request::all();
// ...
}
}
Bien que les façades et les alias soient encore disponibles à Laravel, il est possible et généralement encouragé de suivre la voie de l'injection de dépendance. Par exemple, utiliser l'injection de constructeur pour obtenir le même résultat:
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();
// ...
}
}
Cette approche présente de nombreux avantages, mais à mon avis, le plus grand avantage en matière d’injection de dépendance est qu’elle simplifie le test de votre code. En déclarant les dépendances de vos classes en tant que constructeur ou arguments de méthode, il devient très facile de simuler ces dépendances et de tester votre classe de manière isolée.
je le fais fonctionner avec une définition de la portée
fonction publique pagar (\ Illuminate\Http\Request $ request) {//