web-dev-qa-db-fra.com

Demande Laravel :: all () ne doit pas être appelé de manière statique

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)

69
Moose

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

Modifier

É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');
    }
}
183
patricus

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

}
6
Jonathan Crowe

La façade est une autre classe de requête, accédez-y avec le chemin complet:

$input = \Request::all();
2
Luca C.

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

2
lucidlogic
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());
}
1
Ravi G

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.

0
dotNET

J’ai pensé qu’il serait utile que les futurs visiteurs expliquent un peu ce qui se passe ici.

La classe 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.

Les façades

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:

  • Écouter un appel de méthode statique, dans ce cas, all sans paramètre
  • Saisissez l'objet sous-jacent du conteneur IoC à l'aide de la clé renvoyée par getFacadeAccessor, dans ce cas, un objet Illuminate\Http\Request
  • Appelez dynamiquement la méthode reçue statiquement sur l'objet récupéré. Dans ce cas, 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.

Aliasing

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();

        // ...
    }
}

Une note sur l'injection de dépendance

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.

0
Jonathon

je le fais fonctionner avec une définition de la portée

fonction publique pagar (\ Illuminate\Http\Request $ request) {//

0
Julian Lanfranco