Tutorial de Laravel para principiantes

Laravel fue creado por Taylor Otwell. Desde su lanzamiento inicial en junio de 2011 (versión 1), se ha vuelto cada vez más popular en el sector del framework PHP de la industria del desarrollo web. Gran parte de esta popularidad se puede atribuir a las muchas características pensadas primero para los desarrolladores que vienen de serie.

¿Por qué Laravel?

Alrededor del año 2000, la mayoría Códigos PHP era procesal y podía encontrarse en forma de “guiones” que contendrían una maraña de código espagueti. Incluso las páginas más simples no tenían separación de intereses, y por lo tanto era bastante fácil que una aplicación se convirtiera rápidamente en una pesadilla de mantenimiento. El mundo necesitaba algo mejor... Ingrese PHP versión 5 y una variedad de marcos PHP que intentan brindar una resolución muy necesaria y mejores soluciones a diversos problemas de aplicaciones web.

Desde entonces hemos visto muchos frameworks lanzados que allanarían el camino para los frameworks populares que existen y se utilizan hoy en día. Hoy, los tres principales serían (en nuestra opinión) Zend Framework, Symfony y, por supuesto, Laravel. Aunque cada uno de estos frameworks se fundó en principios similares y están orientados a resolver (básicamente) los mismos problemas comunes, sus diferencias clave radican en sus implementaciones. Cada uno tiene sus propias peculiaridades sobre cómo abordar la solución de problemas. Cuando miras el código producido por cada uno de ellos, verás que hay una línea bastante sólida que los separa entre sí. En nuestra humilde opinión, el framework Laravel es el mejor.

Más información sobre Diferencia entre Laravel y CodeIgniter

Cómo descargar e instalar Laravel con Composer

NOTA Se supone que ya tienes una copia de PHP instalada en tu sistema local. Si no, puedes leer cómo instalarlo. aqui

Composer es un gestor de paquetes y dependencias. Para instalarlo, abre una terminal y haz clic en cd en un nuevo directorio. Ejecuta este comando:

curl -Ss getcomposer.org/installer | php

Los resultados de este comando se verán así:

Nota: Para obtener instrucciones más detalladas sobre cómo configurar Laravel, consulte la documentación de Laravel. aqui.

Verás que se descarga y compila el script composer.phar, que es el que usamos para instalar Laravel. Aunque hay muchas formas de configurar una nueva aplicación Laravel, lo haremos a través del script composer.phar de Laravel. Para instalar este script, ejecuta:

composer global require laravel/installer

Que se verá algo así:

Esto descargará e instalará todos los archivos del framework, así como todas las dependencias que requiere. Los paquetes se guardarán dentro del directorio del proveedor. Una vez que se hayan descargado e instalado, es tan fácil como ejecutar el siguiente comando:

laravel new uploadApp

Verá algo parecido al siguiente resultado:

Composer está instalando todos los paquetes que Laravel necesita para ejecutarse. Puede tardar unos minutos, así que tenga paciencia. Una vez que haya terminado, ejecute el comando ls -al para ver lo que se instaló.

Aquí hay un breve desglose de los directorios en una aplicación Laravel común:

• aplicación/: Esta es la carpeta fuente donde reside el código de nuestra aplicación. Todos los controladores, políticas y modelos están dentro de esta carpeta.
• arranque/: Contiene el script de inicio de la aplicación y algunos archivos de mapas de clases.
• configuración/: Contiene los archivos de configuración de la aplicación. Por lo general, estos no se modifican directamente, sino que se basan en los valores configurados en el archivo .env (entorno) en la raíz de la aplicación.
• base de datos/: Alberga los archivos de la base de datos, incluidas las migraciones, las semillas y las fábricas de prueba.
• público/ : Carpeta de acceso público que contiene recursos compilados y, por supuesto, un archivo index.php
• recursos/ : Contiene activos de front-end como archivos javascript, archivos de idioma, archivos CSS/SASS y todas las plantillas utilizadas en la aplicación (llamadas plantillas blade)
• rutas/ : Todas las rutas de la aplicación están aquí. Hay algunos "alcances" diferentes de rutas, pero en el que nos centraremos es en el archivo web.php.
• almacenamiento/ : Todos los archivos de caché temporales utilizados por la aplicación, archivos de sesión, scripts de vista compilados y archivos de registro
• pruebas/ : Contiene archivos de prueba para la aplicación, como pruebas unitarias y pruebas funcionales.
• proveedor/ : Todos los paquetes de dependencia instalados con Composer

Ahora bien, creemos el resto de la aplicación y ejecútela con un comando artesanal especial (para ahorrarnos la molestia de instalar y configurar un servidor web como Apache o nginx). El archivo .env contiene todos los valores de configuración que los archivos en el directorio /config utilizan para configurar la aplicación. En su interior, notará que el valor de configuración para varios parámetros utilizados por los componentes internos de la aplicación.

Diseño de aplicaciones: un rápido resumen de nuestros requisitos

En este tutorial en línea de Laravel, crearemos una aplicación muy simple que hará solo dos cosas:

1. manejar la carga de archivos desde un formulario web
2. mostrando los archivos cargados anteriormente en una página diferente.

Para este proyecto, nuestra aplicación será de solo escritura, lo que significa que el usuario solo podrá escribir archivos y ver la lista de archivos que ha subido. Esta aplicación es extremadamente básica pero debería servirte como una buena práctica para empezar a desarrollar tus habilidades y conocimientos de Laravel. Tenga en cuenta que, en aras de la brevedad, he excluido el modelado, las migraciones y la autenticación de bases de datos pero, en una aplicación del mundo real, estas son cosas adicionales que deberá considerar.

Aquí hay una lista de componentes que necesitaremos para que la aplicación funcione como se espera:

• A ruta que permitirá que el mundo exterior (Internet) use la aplicación y también especificará el punto final que apuntará a donde se encuentra la lógica para guardar el archivo cargado.
• A controlador que maneja la solicitud al flujo de respuesta
• A plantilla que se utilizará para mostrar una lista de archivos cargados anteriormente y el formulario de carga real en sí
• A solicita que el responsable utilizará para validar los datos introducidos desde el formulario web

¿Qué es una Ruta?

Una ruta en Laravel es básicamente un punto final especificado por un URI que actúa como un "puntero" a alguna funcionalidad ofrecida por la aplicación. Por lo general, una ruta simplemente apunta a un método en un controlador y también dicta qué métodos HTTP pueden acceder a ese URI. Una ruta tampoco siempre significa un método de controlador; También podría simplemente pasar la ejecución de la aplicación a un cierre definido o a una función anónima.

¿Por qué utilizar Ruta?

Las rutas se almacenan dentro de archivos en la carpeta /routes dentro del directorio raíz del proyecto. De manera predeterminada, hay algunos archivos diferentes que corresponden a los diferentes “lados” de la aplicación (“lados” proviene de la metodología de arquitectura hexagonal). Estos incluyen:

• web.php El público orientado a rutas basadas en “navegador”. Estos son los más comunes y son los que ataca el navegador web. Se ejecutan a través del grupo de middleware web y también contienen funciones para protección csrf (que ayuda a defenderse contra ataques y hacks maliciosos basados ​​en formularios) y generalmente contienen un grado de "estado" (con esto quiero decir que utilizan sesiones)
• api.php Rutas que corresponden a un grupo de API y por lo tanto tienen el middleware API habilitado de forma predeterminada. Estas rutas no tienen estado y no tienen sesiones ni memoria de solicitudes cruzadas (una solicitud no comparte datos ni memoria con ninguna otra solicitud; cada una está autoencapsulada).
• console.php Estas rutas corresponden a comandos artesanales personalizados que has creado para tu aplicación.
• canales.php Registra rutas para transmisión de eventos.

El archivo clave que nos debe preocupar en este momento es el específico del navegador, web.php. Ya hay una ruta definida de forma predeterminada, que es la que selecciona cuando navega a la raíz web de su aplicación (la raíz web está en el directorio público). Vamos a necesitar tres rutas diferentes para que funcione nuestra aplicación de carga:

• /upload Este será el URI de la página principal que muestra nuestro formulario web para cargar archivos.
• /proceso Aquí será donde el formulario ubicado en el URI /upload publica los datos enviados por el formulario (la “acción” del formulario).
• /list Esto enumerará todos los archivos cargados en el sitio.

nota Es posible que el punto final /list no sea necesario si deseamos poner toda la lógica para mostrar el formulario de carga y la lista de archivos en una sola página; sin embargo, los mantuvimos separados por ahora para agregar un poco más de materia al tema en cuestión. .

//inside routes/web.php
Route::get('/upload', 'UploadController@upload')->name('upload');
Route::get('/download, 'UploadController@download)->name(‘download');
Route::post('/process', 'UploadController@process')->name('process');
Route::get('/list', 'UploadController@list')->name('list');

En este tutorial del marco Laravel, para cada ruta deseada, la enumeraremos explícitamente en el archivo de rutas web.php usando uno de los métodos de solicitud específicos de HTTP disponibles (get(), post(), put(), delete(), parche() u opciones() ). Para ver un desglose de cada uno de estos, consulte este vídeo afuera. Lo que hacen estos métodos es especificar qué verbos HTTP pueden acceder a esa ruta determinada. Si necesita una ruta para poder aceptar más de un verbo HTTP (lo que podría ser el caso si está utilizando una sola página para mostrar los datos iniciales y publicar los datos del formulario enviado), puede usar Route::any( ) método.

El segundo argumento para los métodos Route::get() y Route::post() (y cualquiera de los otros métodos relacionados con verbos HTTP en la fachada Route) es el nombre de un controlador específico y el método alojado dentro de ese controlador que se ejecuta al llegar al punto final de la ruta con la solicitud HTTP permitida (GET, POST, PATCH, etc.). Estamos usando UploadController para las tres rutas y las hemos especificado de la siguiente manera:

El último método que llamamos en cada ruta es su función name(), que acepta una sola cadena como argumento y se utiliza para "etiquetar" más o menos una ruta en particular con un nombre fácil de recordar (en nuestros casos, cargar, procesar y listar). Me doy cuenta de que no parece una característica tan buena darle a cada ruta su propio nombre cuando la URL tiene exactamente el mismo nombre, pero realmente resulta útil cuando tienes una ruta específica como /users/profile/dashboard/config, que sería más fácil de recordar como perfil-admin o usuario-config.

Una nota sobre fachadas:

• Las fachadas proporcionan una interfaz "estática" para las clases que están disponibles en el contenedor de servicios de la aplicación".
• Proporcionan una sintaxis concisa y memorable que le permite utilizar las funciones de Laravel sin recordar nombres de clases largos que deben inyectarse o configurarse manualmente.

En las definiciones de ruta anteriores en este tutorial del marco de Laravel, utilizamos la fachada Ruta en lugar de crear manualmente una instancia de un nuevo objeto Illuminate/Routing/Router y llamar a los métodos correspondientes en ese objeto. Es solo un atajo que ahorra escribir. Las fachadas se utilizan mucho en todo el marco de Laravel; puedes y debes familiarizarte más con ellas. Los documentos para Fachadas se pueden encontrar. aqui.

¿Qué es un controlador?

Un controlador es la “C” de la arquitectura “MVC” (Modelo-Vista-Controlador), en la que se basa Laravel. El trabajo de un controlador se puede resumir en esta sencilla definición: Recibe la solicitud del cliente y devuelve una respuesta al cliente. Esta es la definición básica y también los requisitos mínimos de cualquier controlador determinado. Lo que hace entre esas dos cosas generalmente se considera la “acción” del controlador (o la “implementación de la ruta”). Actúa como el segundo punto de entrada a la aplicación (el primero es la solicitud) para el cliente, quien envía la carga útil de la solicitud (que veremos a continuación) a la aplicación, esperando algún tipo de respuesta (en forma de página de éxito, redireccionamiento, página de error o cualquier otro tipo de respuesta HTTP).

Un controlador hace (básicamente) lo mismo que una definición de ruta con una función anónima configurada como "acción" cuando se llega a esa ruta. La diferencia es que un controlador soporta bien la separación de preocupaciones mientras que una ruta se define en línea con la definición de URL real, lo que básicamente significa que estamos acoplando el URI asignado a la ruta con la implementación de la ruta, o el código que se ejecuta cuando esa ruta es golpear.

Por ejemplo, los siguientes dos fragmentos de código lograrán lo mismo:

Ejemplo #1: Definición e implementación de la ruta dentro de una sola llamada a un método (en el archivo de rutas web.php)

//inside routes/web.php
<?php
Route::get('/hello-world', function(Request $request) {
   $name = $request->name;
   return response()->make("<h1>Hello World! This is ".$name, 200);
});

Ejemplo #2: La definición de ruta está dentro de route/web.php, pero su implementación reside dentro de la clase /app/Http/Controllers/HelloWorldController

//inside routes/web.php
<?php

Route::get('/hello-world', 'HelloWorldController@index')->name('hello-world');

------------------------------------------------------------------------------------
//inside app/Http/Controllers/HelloWorldController.php
<?php
namespace App\Http\Controllers;
use Illuminate\Http\Request;

class HelloWorldController extends Controller
{
   public function index(Request $request)
   {
       $name = $request->name;
       return response()->make("<h1>Hello World! This is ".$name, 200);
   }
}

Aunque el ejemplo n.º 2 de Laravel parece mucho más trabajo (que no lo es, solo un poco más de código es todo), observe los beneficios que obtenemos al colocar nuestra lógica de acción para la ruta "hola-mundo" dada dentro de un controlador. de con la definición de la ruta como una función de devolución de llamada:

1. Nuestra lógica está claramente separada en su propia clase (separación de preocupaciones)
2. Nuestro controlador está configurado para una extensión posterior si necesitamos agregarle capacidades adicionales... Digamos que tal vez queremos agregar una función de "adiós mundo"... En este caso, cambiaríamos el nombre del controlador a un "HelloController" más genérico y luego definiríamos dos métodos separados, Hola() y el adiós(). También necesitaríamos definir dos rutas separadas que mapearan el /Hola y el /adiós URI a su método apropiado en el controlador. Esto es deseable en comparación con engordar un archivo de rutas con la implementación de cada ruta definida como funciones de devolución de llamada.
3. Laravel tiene la capacidad incorporada de almacenar en caché todas las definiciones de ruta en la aplicación para acelerar el tiempo que lleva encontrar una ruta determinada (aumenta el rendimiento de la aplicación); sin embargo, solo podrá aprovechar esto si todas sus rutas definidas dentro de la aplicación están configuradas usando asignaciones específicas del controlador (consulte el Ejemplo #2 arriba)

Ejecutemos este comando que generará un nuevo controlador para nosotros.

// ...inside the project's root directory:
php artisan make:controller UploadController   

Básicamente, lo que hace este comando es generar un código auxiliar para un controlador llamado "UploadController" dentro del directorio principal del controlador en /app/Http/Controllers/UploadController.php. Siéntete libre de abrir ese archivo y echarle un vistazo. Es muy simple porque es sólo una versión eliminada del controlador, con la ruta del espacio de nombres correcta y las clases requeridas desde las que se extiende.

Generando la solicitud

Antes de continuar con este tutorial de PHP Laravel y realizar algunos cambios en el stub generado de UploadController, creo que tendrá más sentido crear primero la clase de solicitud. Esto se debe a que el método del controlador que maneja la solicitud debe indicar el tipo del objeto de solicitud en su firma, lo que le permite validar automáticamente los datos del formulario entrante (como se especifica en el método rules(). Más sobre eso más adelante...) Por ahora, usemos el comando artisan nuevamente para generar nuestro stub de solicitud:

php artisan make:request UploadFileRequest

Este comando generará un archivo llamado UploadFileRequest dentro de app/Http/Requests/UploadFileRequest. Abra el código auxiliar y eche un vistazo... Lo encontrará muy simple, ya que contiene solo dos métodos, autorización() y reglas.

Creando la lógica de validación

Modifiquemos el talón de solicitud para satisfacer las necesidades de nuestra aplicación. Modifique el archivo para que se vea así:

<?php

namespace App\Http\Requests;

use Illuminate\Foundation\Http\FormRequest;

class UploadFileRequest extends FormRequest
{
   /**
    * Determine if the user is authorized to make this request.
    *
    * @return bool
    */
   public function authorize()
   {
       return true;
   }

   /**
    * Get the validation rules that apply to the request.
    *
    * @return array
    */
   public function rules()
   {
       return [
           'fileName' => 'required|string',
           'userFile' => 'required|file'
       ];
   }
}

No hay muchos cambios, pero observe que el método Authorize() ahora devuelve verdadero en lugar de falso. Este método decide si se permite o no que la solicitud ingrese a la aplicación. Si se establece en falso, impide que la solicitud ingrese al sistema (que normalmente sería un método en el controlador). Este sería un lugar muy útil para realizar comprobaciones de autorización del usuario o cualquier otra lógica que pueda decidir si la solicitud puede pasar al controlador. Por ahora, aquí simplemente devolvemos verdadero para permitir que cualquier cosa use la solicitud.

El otro método, reglas() es donde entra en juego toda la magia con respecto a la validación. La idea es simple: devolver una matriz que contenga un conjunto de reglas en forma de:

'formFieldName' => 'constraints this field has separated by pipe characters (|)'

Hay muchas restricciones de validación diferentes que Laravel admite de manera predeterminada. Para obtener una lista completa de ellas, consulte la documentación en línea. aquiPara nuestra aplicación de carga, habrá dos campos que se pasan a través de una solicitud POST desde un formulario en el front-end. El parámetro fileName debe incluirse dentro del cuerpo del formulario (es decir, es obligatorio) y se utiliza como el nombre de archivo con el que almacenaremos el archivo en el almacenamiento (esto se hace en el controlador; lo abordaremos un poco más adelante). También especificamos que el nombre del archivo debe ser una cadena agregando un carácter de barra vertical (|) y la palabra "cadena". Las restricciones siempre están delimitadas por barras verticales, lo que le permite especificar cualquier criterio adicional para el campo dado en una sola línea. ¡Qué poder!

El segundo parámetro, userFile, es el archivo real que el usuario carga desde un formulario en una página web. UserFile también es necesario y deben ser un archivo. Nota: Si esperáramos que el archivo cargado fuera una imagen, entonces usaríamos la restricción de imagen, lo que limitaría los tipos de archivos aceptados como uno de los tipos de imágenes populares (jpeg, png, bmp, gif o svg). Como queremos permitir que el usuario cargue cualquier tipo de archivo, simplemente mantendremos la restricción de validación de archivos.

Eso es todo lo que hay que hacer con el objeto de solicitud. Su trabajo principal es simplemente mantener el conjunto aceptable de criterios (restricciones) que los parámetros del cuerpo del formulario deben satisfacer para poder avanzar más profundamente en la aplicación. Otra cosa a tener en cuenta es que estos dos campos (userFile y filename) también deben especificarse dentro del código HTML en forma de campos de entrada (con el nombre del campo correspondiente al nombre dentro del objeto de solicitud).

Quizás se pregunte: seguro que esto define las características de lo que debe contener una solicitud de formulario, pero ¿dónde se realiza la verificación real de estas restricciones? Hablaremos de eso a continuación.

Modificar el controlador

Abra la aplicación/Http/Controllers/UploadController y realice los siguientes cambios:

<?php

namespace App\Http\Controllers;

use Illuminate\Contracts\Container\BindingResolutionException;
use Illuminate\Http\Request;
use App\Http\Requests\UploadFileRequest; //our new request class
use Illuminate\Support\Facades\Storage; 

class UploadController extends Controller
{
   /**
    * This is the method that will simply list all the files uploaded by name and provide a
    * link to each one so they may be downloaded
    *
    * @param $request : A standard form request object
    * @return \Illuminate\Contracts\View\Factory|\Illuminate\View\View
    * @throws BindingResolutionException
    */
   public function list(Request $request)
   {
       $uploads = Storage::allFiles('uploads');

       return view('list', ['files' => $uploads]);
   }

   /**
    * @param $file
    * @return \Symfony\Component\HttpFoundation\BinaryFileResponse
    * @throws BindingResolutionException
    */
   public function download($file)
   {
       return response()->download(storage_path('app/'.$file));
   }

   /**
    * @return \Illuminate\Contracts\View\Factory|\Illuminate\View\View
    * @throws BindingResolutionException
    */
   public function upload()
   {
       return view('upload');
   }

   /**
    * This method will handle the file uploads. Notice that the parameter's typehint
    * is the exact request class we generated in the last step. There is a reason for this!
    *
    * @param $request : The special form request for our upload application
    * @return array|\Illuminate\Http\UploadedFile|\Illuminate\Http\UploadedFile[]|null
    * @throws BindingResolutionException
    */
   public function store(UploadFileRequest $request)
   {
       //At this point, the parameters passed into the $request (from form) are
       //valid--they satisfy each of the conditions inside the rules() method

       $filename = $request->fileName;    //parameters have already been validated
       $file = $request->file('userFile'); //that we don't need any additional isset()

       $extension = $file->getClientOriginalExtension(); //grab the file extension
       $saveAs = $filename . "." . $extension; //filename to save file under

       $file->storeAs('uploads', $saveAs, 'local'); //save the file to local folder

       return response()->json(['success' => true]); //return a success message
   }
}

Por lo tanto, es un método bastante sencillo para guardar los archivos cargados en el disco. Aquí hay un desglose del método upload() anterior:

• Escriba una pista de la clase de solicitud en el método del controlador que realiza la funcionalidad "carne y patatas" para que podamos validar automáticamente los datos entrantes.
• Tome el archivo del objeto de solicitud (ahora validado) dentro del método del controlador (en este caso lo hemos llamado upload() pero también podría haber sido nombrado con un nombre más estandarizado como store()).
• Saque el nombre del archivo de la solicitud
• Genere el nombre de archivo final que se utilizará para guardar el archivo. El método getClientOriginalExtension() simplemente toma la extensión original del archivo cargado.
• Almacene el archivo en el sistema de archivos local utilizando su método storeAs(), pasando la ruta nombrada dentro del directorio /storage como primer argumento y el nombre del archivo para guardarlo como segundo.
• Devolver una respuesta JSON indicando que la solicitud fue exitosa

La plantilla de la hoja

La última pieza importante de este rompecabezas es la plantilla de la hoja, que contendrá todo el código HTML, CSS y JavaScript para nuestra sencilla aplicación. Aquí está el código. Lo explicaremos más adelante.

<body>
   <h1>Upload a file</h1>
   <form id="uploadForm" name="uploadForm" action="{{route('upload')}}" enctype="multipart/form-data">
       @csrf
       <label for="fileName">File Name:</label>
       <input type="text" name="fileName" id="fileName" required /><br />
       <label for="userFile">Select a File</label>
       <input type="file" name="userFile" id="userFile" required />
       <button type="submit" name="submit">Submit</button>
   </form>
   <h2 id="success" style="color:green;display:none">Successfully uploaded file</h2>
   <h2 id="error" style="color:red;display:none">Error Submitting File</h2>
   <script src="//ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js"></script>
   <script>
        $('#uploadForm').on('submit', function(e) {
            e.preventDefault();
            var form = $(this);
            var url = form.attr('action');
            $.ajax({
                url: url,
                type: "POST",
                data: new FormData(this),
                processData: false,
                contentType: false,
                dataType: "JSON",
                success: function(data) {
                    $("#fileName").val("");
                    $("#userFile").val("");
                }
            }).done(function() {
                $('#success').css('display', 'block');
                window.setTimeout(()=>($("#success").css('display', 'none')), 5000);
            }).fail(function() {
                $('#error').css('display', 'block');
                window.setTimeout(()=>($("#error").css('display', 'none')), 5000);
            });
        });
   </script>
</body>
</html>

Esto es lo que nuestro /subir la página se parece a:

Este es un ejemplo muy típico de un archivo blade que contiene un formulario HTML y javascript/jQuery para agregar funcionalidad asincrónica (para que la página no se actualice). Hay un etiqueta sin atributo de método (que explicaré en un segundo) y con un curioso atributo de acción con el valor {{route('file.upload')}}. En Blade, esto es lo que se conoce como una Directiva. Una directiva es simplemente un nombre elegante para una función: son funciones específicas de las plantillas de Blade que realizan diferentes operaciones que son comunes para la construcción de páginas web y aplicaciones web. Para comprender mejor todas las cosas interesantes que Blade puede hacer, consulte la documentación aqui. En el caso anterior, estamos usando la directiva de ruta para generar una URL para el envío de nuestro formulario.

Recuerde que definimos nuestras rutas anteriormente en la aplicación dentro del archivo web.php, especificando un nombre fácil de recordar para cada una de ellas. La directiva {{route()}} acepta el nombre de una ruta, lo busca dentro de la lista de rutas almacenadas en caché internamente y genera una URL completa basada en la definición de esa ruta en el archivo web.php. Para este primer caso, especificamos que queremos que el formulario envíe los datos enviados a la URL /proceso de nuestra aplicación, que se define como un PUBLICAR ruta.

La siguiente cosa extraña que quizás hayas notado es la etiqueta @csrf justo debajo de la etiqueta del formulario de apertura. En Blade, esta etiqueta genera un parámetro _token en el formulario, que se verifica dentro de la aplicación antes de que se permita procesar los datos del formulario. Esto garantiza que los datos dentro del formulario tengan un origen válido y evita ataques de falsificación de solicitudes entre sitios. Para obtener más información sobre esto, consulte el documentos.

Después de esto definimos nuestro formulario como normal, sin embargo, tenga en cuenta que los nombres de nuestros parámetros de formulario, userFile y fileName son los exactamente el mismo como se define dentro de nuestro objeto de solicitud. Si olvidamos incluir una entrada para un parámetro dado que estaba definido en el objeto de solicitud (o lo escribimos mal), la solicitud fallaría y se devolvería un error, impidiendo que la solicitud del formulario original llegue al método del controlador ubicado en UploadController@ proceso .

Continúe, pruébelo y envíe algunos archivos a la aplicación mediante este formulario. Luego, navegue hasta el /lista página para ver el contenido de la carpeta de carga, con los archivos que cargó enumerados en una tabla:

The Bigger Picture

Demos un paso atrás y veamos lo que hemos hecho en este tutorial de Laravel.

Este diagrama muestra la aplicación tal como está actualmente (sin incluir detalles de alto nivel):

Debe recordar que el objeto de solicitud que construimos al comienzo de este tutorial de Laravel debe tener los mismos parámetros definidos en su método de reglas que en el formulario de la plantilla de hoja (si no, vuelva a leer la sección "Creación de la lógica de validación"). . El usuario ingresa el formulario en una página web que se representa a través de un motor de plantilla Blade (este proceso, por supuesto, está en piloto automático, por lo que ni siquiera tenemos que pensar en ello) y envía el formulario. El código jQuery de la plantilla en la parte inferior detiene el envío predeterminado (que redirigiría automáticamente a una página separada), crea una solicitud ajax, carga la solicitud con los datos del formulario y carga el archivo, y envía todo a la primera capa de nuestro aplicación: la petición.

El objeto de solicitud se completa asociando los parámetros dentro del método reglas() con los parámetros del formulario enviado y luego valida los datos de acuerdo con cada regla especificada. Si se cumplen todas las reglas, la solicitud se pasa a cualquier método de controlador que corresponda a los valores definidos en el archivo de ruta web.php. En este caso, es el método Process() del UploadController el que hace el trabajo. Una vez que accedemos al controlador, ya sabemos que la solicitud pasó la validación, por lo que no tenemos que volver a probar si el nombre de archivo proporcionado es, de hecho, una cadena o si el parámetro userFile realmente contiene algún tipo de archivo... Podemos continuar como normal.

Luego, el método del controlador toma los parámetros validados del objeto de solicitud, genera un nombre de archivo completo al concatenar el parámetro fileName pasado con la extensión original de userFile, almacena el archivo dentro de un directorio en nuestra aplicación y luego devuelve un archivo simple codificado en JSON. respuesta verificando que la solicitud fue exitosa. La respuesta es recibida por la lógica jQuery, que realiza algunas tareas más relacionadas con la interfaz de usuario, como mostrar el mensaje de éxito (o error) durante 5 segundos y luego ocultarlo y borrar las entradas del formulario anterior... esto es para que el usuario lo sepa. para asegurarse de que la solicitud fue exitosa y pueden cargar otro archivo, si así lo desean.

Además, fíjate en el diagrama anterior dónde se traza la línea entre el cliente y el servidor. Es absolutamente fundamental que entiendas este concepto y te ayudará a resolver problemas y cuestiones que puedas tener en el futuro cuando hagas malabarismos, por ejemplo, con múltiples solicitudes asincrónicas que pueden ocurrir en un momento dado. La separación está justo en el límite del objeto de solicitud. El objeto de solicitud en sí puede considerarse como la "puerta de entrada" al resto de la aplicación... Realiza la validación inicial y el registro de los valores del formulario que se pasan desde el navegador web. Si se consideran válidos, continúa hasta el controlador. Todo lo anterior está en el front-end (el "cliente" significa literalmente "en la computadora del usuario"). La respuesta se devuelve desde la aplicación al lado del cliente, donde nuestro código jQuery escucha pacientemente su llegada y realiza algunas tareas de interfaz de usuario simples una vez que la recibe.

Hemos cubierto más de 90 preguntas frecuentes importantes. Preguntas de entrevista relacionadas con Laravel y PHP para que los candidatos nuevos y experimentados consigan el trabajo adecuado.