Solicitud de Laravel :: all () no debe llamarse estáticamente

En Laravel, estoy tratando de llamar $input = Request::all();a un store()método en mi controlador, pero obtengo el siguiente error:

El método Illuminate\Http\Request::all()no estático no debe llamarse estáticamente, asumiendo que se trata $thisde un contexto incompatible

¿Alguna ayuda para descubrir la mejor manera de corregir esto? (Estoy siguiendo un Laracast)

El mensaje de error se debe a que la llamada no atraviesa la Requestfachada.

Cambio

use Illuminate\Http\Request;

A

use Request;

y debería empezar a funcionar.

En el archivo config / app.php, puede encontrar una lista de los alias de clases. Allí, verá que la clase base Requesttiene un alias para la Illuminate\Support\Facades\Requestclase. Debido a esto, utilizar la Requestfachada en un archivo de espacio de nombres, es necesario especificar el uso de la clase base: use Request;.

Editar

Dado que esta pregunta parece generar algo de tráfico, quería actualizar un poco la respuesta ya que Laravel 5 se lanzó oficialmente.

Si bien lo anterior sigue siendo técnicamente correcto y funcionará, la use Illuminate\Http\Request;declaración se incluye en la nueva plantilla del controlador para ayudar a impulsar a los desarrolladores en la dirección de usar la inyección de dependencia en lugar de confiar en la fachada.

Al inyectar el objeto Request en el constructor (o métodos, como están disponibles en Laravel 5), es el Illuminate\Http\Requestobjeto el que debe inyectarse, y no la Requestfachada.

Por lo tanto, en lugar de cambiar la plantilla del Controlador para que funcione con la fachada de Solicitud, es mejor trabajar con la plantilla del Controlador dada y avanzar hacia el uso de la inyección de dependencia (a través del constructor o métodos).

Ejemplo mediante método

<?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');
    }
}

Ejemplo vía constructor

<?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');
    }
}

Inyecte el objeto de solicitud en el controlador usando la inyección mágica de Laravel y luego acceda a la función de forma no estática. Laravel inyectará automáticamente dependencias concretas en clases cargadas automáticamente

class MyController() 
{

   protected $request;

   public function __construct(\Illuminate\Http\Request $request)
   {
       $this->request = $request;
   }

   public function myFunc()
   {
       $input = $this->request->all();
   }

}

use el request()ayudante en su lugar. No tiene que preocuparse por las usedeclaraciones y, por lo tanto, este tipo de problema no volverá a ocurrir.

$input = request()->all();

sencillo

La fachada es otra clase de Solicitud, acceda a ella con la ruta completa:

$input = \Request::all();

Desde laravel 5 también puedes acceder a él a través de la request()función:

$input = request()->all();

Pensé que sería útil para los futuros visitantes dar una pequeña explicación sobre lo que está sucediendo aquí.

La Illuminate\Http\Requestclase

La Illuminate\Http\Requestclase de Laravel tiene un método llamado all(de hecho, el allmétodo está definido en un rasgo que Requestusa la clase, llamado Illuminate\Http\Concerns\InteractsWithInput). La firma del allmétodo en el momento de escribir este artículo se ve así:

public function all($keys = null)

Este método no se define como staticy, por lo tanto, cuando intenta llamar al método en un contexto estático, es decir Illuminate\Http\Request::all(), obtendrá el error que se muestra en la pregunta de OP. El allmétodo es un método de instancia y trata con información que está presente en una instancia de la Requestclase, por lo que llamarlo de esta manera no tiene sentido.

Fachadas

Una fachada en Laravel proporciona a los desarrolladores una forma conveniente de acceder a objetos en el contenedor de IoC y llamar a métodos en esos objetos. Un desarrollador puede llamar a un método "estáticamente" en una fachada como Request::all(), pero la llamada al método real en el objeto real noIlluminate\Http\Request es estática.

Una fachada funciona como un proxy: se refiere a un objeto en el contenedor de IoC y pasa la llamada al método estático a ese objeto (de forma no estática). Por ejemplo, tome la Illuminate\Support\Facades\Requestfachada, así es como se ve:

class Request extends Facade
{
    protected static function getFacadeAccessor()
    {
        return 'request';
    }
}

Bajo el capó, la Illuminate\Support\Facades\Facadeclase base usa algo de magia PHP, es decir, el __callStaticmétodo para:

• Escuche una llamada a un método estático, en este caso allsin parámetros
• Agarre el objeto subyacente del contenedor de IoC utilizando la clave devuelta por getFacadeAccessor, en este caso un Illuminate\Http\Requestobjeto
• Llame dinámicamente al método que recibió estáticamente en el objeto que ha recuperado, en este caso allse llama de forma no estática en una instancia de Illuminate\Http\Request.

Es por eso que, como @patricus señaló en su respuesta anterior, al cambiar la usedeclaración / import para hacer referencia a la fachada, el error ya no está allí, porque en lo que respecta a PHP, allse ha llamado correctamente en una instancia de Illuminate\Http\Request.

Aliasing

La creación de alias es otra característica que Laravel proporciona para mayor comodidad. Funciona creando efectivamente clases de alias que apuntan a fachadas en el espacio de nombres raíz. Si echa un vistazo a su config/app.phparchivo, debajo de la aliasesclave, encontrará una larga lista de asignaciones de cadenas a clases de fachada. Por ejemplo:

'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 crea estas clases de alias para usted, en función de su configuración y esto le permite utilizar las clases disponibles en el espacio de nombres raíz (como se indica en las claves de cadena de la aliasesconfiguración) como si estuviera usando la propia fachada:

use Request:

class YourController extends Controller
{
    public function yourMethod()
    {
        $input = Request::all();

        // ...
    }
}

Una nota sobre la inyección de dependencia

Si bien las fachadas y el aliasing todavía se proporcionan en Laravel, es posible y generalmente se recomienda seguir la ruta de inyección de dependencia. Por ejemplo, usando la inyección del constructor para lograr el mismo resultado:

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

        // ...
    }
}

Hay una serie de beneficios en este enfoque, pero en mi opinión personal, la mayor ventaja de la inyección de dependencia es que hace que su código sea más fácil de probar. Al declarar las dependencias de sus clases como argumentos de constructor o método, resulta muy fácil simular esas dependencias y realizar pruebas unitarias en su clase de forma aislada.

use Illuminate\Http\Request;
public function store(Request $request){
   dd($request->all());
}

es lo mismo en el contexto diciendo

use Request;
public function store(){
   dd(Request::all());
}

también sucede cuando importa la siguiente biblioteca al archivo api.php. esto sucede por la sugerencia de algunos IDE de importarlo por no encontrar la clase de ruta .

simplemente quítelo y todo funcionará bien.

use Illuminate\Routing\Route;

actualizar:

parece que si agrega esta biblioteca no dará lugar a un error

use Illuminate\Support\Facades\Route;

Estaba enfrentando este problema incluso con la use Illuminate\Http\Request;línea en la parte superior de mi controlador. Seguí tirando de mi cabello hasta que me di cuenta de que estaba haciendo en $request::ip()lugar de $request->ip(). Puede sucederle si no durmió en toda la noche y está mirando el código a las 6 am con los ojos entreabiertos.

Espero que esto ayude a alguien en el futuro.

lo hago funcionar con una definición de alcance

función pública pagar (\ Illuminate \ Http \ Request $ request) {//