Tutorial de Laravel para principiantes

¿Qué es Laravel?

Laravel es un marco web MVC de código abierto para PHP. Laravel es un marco robusto que proporciona un desarrollo sencillo de aplicaciones web PHP con características como un sistema de empaquetado modular con un administrador de dependencias dedicado, acceso a bases de datos relacionales y otras utilidades para la implementación y el mantenimiento de aplicaciones.

Laravel fue creado por Taylor Otwell. Desde su lanzamiento inicial en junio de 2011 (versión 1), ha ganado popularidad de forma constante en el sector de los frameworks PHP para el desarrollo web. Gran parte de esta popularidad se debe a las numerosas funcionalidades que incluye de forma predeterminada, pensadas para el desarrollador.

¿Por qué Laravel?

Alrededor del año 2000, la mayoría Código 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 interesesPor lo tanto, era bastante fácil que una aplicación se convirtiera rápidamente en una pesadilla de mantenimiento. El mundo necesitaba algo mejor. Así llegó PHP versión 5 y una variedad de frameworks de PHP que intentaban aportar la estructura necesaria y mejores soluciones a diversos problemas de las aplicaciones web.

Desde entonces, hemos visto el lanzamiento de numerosos frameworks que sentaron las bases de los frameworks populares que se utilizan hoy en día. Actualmente, los tres mejores serían (en nuestra opinión) Zend Framework, Symfony y, por supuesto, Laravel. Si bien cada uno de estos frameworks se basa en principios similares y está orientado a resolver (básicamente) los mismos problemas comunes, sus principales diferencias radican en sus implementaciones. Cada uno tiene sus propias particularidades en la forma de abordar los problemas. Al analizar el código producido por cada uno de ellos, se observa una clara distinción entre ellos. En nuestra humilde opinión, el framework Laravel es el mejor.

Aprenda más sobre la diferencia entre Laravel y CodeEncendedor.

Cómo descargar e instalar Laravel con Composer

Nota: Este tutorial fue escrito para Laravel 5.8, pero los conceptos de enrutamiento, controlador, solicitud y Blade siguen siendo los mismos en las versiones actuales. A fecha de 2026, la última versión es Laravel 13 (lanzada en marzo de 2026), que requiere PHP 8.3 o posterior, mientras que Laravel 12 requiere PHP 8.2.

Nota: Se da por sentado que ya tienes una copia de PHP instalada en tu sistema local. Si no es así, puedes leer cómo instalarla. aquí.

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 la configuración de Laravel, consulte la documentación de Laravel. aquí.

Verás que se descarga y compila el script composer.phar, que es el que usamos para instalar Laravel. Aunque existen numerosas formas de configurar una nueva aplicación Laravel, lo haremos mediante el script composer 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 necesarias. Los paquetes se guardarán dentro del directorio vendor. Una vez descargado e instalado, basta con ejecutar el siguiente comando:

laravel new uploadApp

Verá algo parecido al siguiente resultado:

Composer está instalando todos los paquetes que Laravel necesita para funcionar. Esto puede tardar unos minutos, así que ten paciencia. Una vez finalizado, ejecuta el comando `ls -al` para ver qué paquetes se han instalado.

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

• aplicación/: Esta es la carpeta de origen donde reside el código de nuestra aplicación. Todos los controladores, políticas y modelos se encuentran dentro de esta carpeta.
• arranque/: Contiene el script de inicio de la aplicación y algunos archivos de mapeo de clases.
• configuración/: Contiene los archivos de configuración de la aplicación. Estos archivos normalmente no se modifican directamente, sino que dependen de los valores configurados en el archivo .env (entorno) ubicado en la raíz de la aplicación.
• base de datos/: Contiene los archivos de la base de datos, incluidas las migraciones, las semillas y las fábricas de pruebas.
• público/ : Carpeta de acceso público que contiene los archivos compilados y, por supuesto, un archivo index.php.
• recursos/ : Contiene recursos de interfaz de usuario como JavaArchivos de script, archivos de idioma, archivos CSS/SASS y todas las plantillas utilizadas en la aplicación (denominadas plantillas blade).
• rutas/ : Todas las rutas de la aplicación se encuentran aquí. Existen diferentes "ámbitos" 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 dependencias se instalaron con Composer.

Ahora bien, vamos a completar el resto de la aplicación y ejecutarla con un comando especial de Artisan (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 del directorio /config utilizan para configurar 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. Mostrar los archivos previamente subidos 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 buena práctica para que empieces a desarrollar tus habilidades y conocimientos de Laravel. Ten en cuenta que, por brevedad, hemos omitido el modelado de bases de datos, las migraciones y la autenticación, pero en una aplicación real, estos son aspectos adicionales que deberás considerar.

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

• A ruta Esto permitirá que el mundo exterior (internet) utilice la aplicación, además de especificar el punto final que apuntará a la ubicación de la lógica para guardar el archivo subido.
• A controlador que gestiona el flujo de solicitud a respuesta.
• A plantilla que se utilizará para mostrar una lista de los archivos subidos previamente y el formulario de carga propiamente dicho.
• A solicita que el controlador utilizará para validar los datos enviados desde el formulario web.

¿Qué es una Ruta?

En Laravel, una ruta es básicamente un punto final especificado por una URI que actúa como un puntero a alguna funcionalidad de la aplicación. Generalmente, una ruta apunta a un método de un controlador y también determina qué métodos HTTP pueden acceder a esa URI. Una ruta no siempre se refiere a un método de controlador; también puede simplemente delegar la ejecución de la aplicación a una función anónima o un Closure definido.

¿Por qué usar una 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: las rutas públicas basadas en el navegador. Estas son las más comunes y son las que recibe el navegador web. Se ejecutan a través del grupo de middleware web y también contienen funcionalidades para Protección CSRF (lo que ayuda a defenderse de ataques maliciosos basados ​​en formularios) y generalmente contienen cierto grado de "estado" (con esto queremos decir que utilizan sesiones).
• api.php: rutas que corresponden a un grupo de API y, por lo tanto, tienen el middleware de API habilitado por defecto. Estas rutas no tienen estado y no tienen sesiones ni memoria entre solicitudes (una solicitud no comparte datos ni memoria con ninguna otra; cada una está encapsulada de forma independiente).
• console.php: estas rutas corresponden a comandos personalizados de Artisan que has creado para tu aplicación.
• channels.php: registra rutas para la transmisión de eventos.

El archivo clave que debemos tener en cuenta en este momento es el específico del navegador, web.php. Ya existe una ruta definida por defecto, que es la que se selecciona al navegar a la raíz web de la aplicación (la raíz web se encuentra en el directorio público). Necesitaremos tres rutas diferentes para que nuestra aplicación de carga funcione:

• /upload: esta será la URI de la página principal que muestra nuestro formulario web para subir archivos.
• /process: aquí es donde el formulario ubicado en la URI /upload envía los datos que ha enviado (la “acción” del formulario).
• /list: esto mostrará una lista de todos los archivos subidos al sitio.

Nota: Puede que no sea necesario el punto final /list si quisiéramos poner toda la lógica para mostrar el formulario de carga y la lista de archivos en una sola página; sin embargo, por ahora los hemos mantenido separados para añadir un poco más de información 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 framework Laravel, para cada ruta deseada, la listaremos explícitamente en el archivo de rutas web.php utilizando uno de los métodos de solicitud HTTP específicos disponibles (get(), post(), put(), delete(), patch() u options()). Para obtener un desglose de cada uno de ellos, consulte este vídeo Estos métodos especifican qué verbos HTTP pueden acceder a esa ruta. Si necesitas que una ruta acepte más de un verbo HTTP (lo cual podría ocurrir si usas una sola página para mostrar los datos iniciales y enviar los datos del formulario), puedes usar el método Route::any().

El segundo argumento de los métodos Route::get() y Route::post() (y de cualquier otro método relacionado con verbos HTTP en la fachada Route) es el nombre de un controlador específico y el método que contiene dicho controlador y que se ejecuta al acceder al punto final de la ruta con la solicitud HTTP permitida (GET, POST, PATCH, etc.). Estamos utilizando UploadController para todas las 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 más o menos “etiquetar” una ruta en particular con un nombre fácil de recordar (en nuestros casos, upload, process y list). Puede que no parezca una gran característica darle a cada ruta su propio nombre cuando URL Tiene exactamente el mismo nombre, pero resulta muy útil cuando se tiene una ruta específica como /users/profile/dashboard/config, que sería más fácil de recordar como profile-admin o user-config.

Una nota sobre las 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, utilizamos la fachada Route en lugar de instanciar manualmente un nuevo objeto Illuminate/Routing/Router y llamar a los métodos correspondientes en ese objeto. Es simplemente un atajo que ahorra tiempo.pingLas fachadas se utilizan mucho en todo el framework Laravel; puedes y debes familiarizarte más con ellas. La documentación sobre fachadas se puede encontrar aquí.

¿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 le devuelve una respuesta. Esta es la definición básica y también el requisito mínimo de cualquier controlador. Lo que hace entre estos dos puntos se considera generalmente 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, redirección, 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 establecida como la "acción" cuando se accede a esa ruta. La diferencia es que un controlador se adapta bien a la separación de responsabilidades, mientras que una ruta se define en línea con el código real. URL definición, 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 se accede a esa ruta.

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 n.° 2: La definición de la ruta se encuentra dentro de routes/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 parezca mucho más trabajoso (lo cual no es cierto, solo un poco más de código), observe los beneficios que obtenemos al colocar nuestra lógica de acción para la ruta "hello-world" dada dentro de un controlador en lugar 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 responsabilidades).
2. Nuestro controlador está configurado para extenderse más adelante si necesitáramos agregarle capacidades adicionales. Digamos que quisiéramos agregar una función de "adiós al 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 adiós(). También necesitaríamos definir dos rutas separadas que mapearan el /Hola y /adiós Las URI se vinculan al método correspondiente en el controlador. Esto es preferible a sobrecargar un archivo de rutas con la implementación de cada ruta definida como una función 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ás aprovechar esto si todas las rutas definidas dentro de la aplicación están configuradas mediante un mapa específico del controlador.pings (véase el ejemplo n.º 2 anterior).

Vamos a ejecutar este comando que generará un nuevo controlador para nosotros.

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

Básicamente, este comando genera un archivo auxiliar para un controlador llamado "UploadController" dentro del directorio principal de controladores en /app/Http/Controllers/UploadController.php. Puedes abrir ese archivo y echarle un vistazo. Es muy sencillo, ya que se trata solo de una versión básica del controlador, con la ruta de espacio de nombres correcta y las clases necesarias de las que hereda.

Generando la solicitud

Antes de continuar con este tutorial de PHP Laravel y realizar algunos cambios en el stub generado del UploadController, conviene crear primero la clase de solicitud. Esto se debe a que el método del controlador que gestiona la solicitud debe especificar 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(); hablaremos de ello más adelante). Por ahora, usemos de nuevo el comando artisan para generar nuestro stub de solicitud:

php artisan make:request UploadFileRequest

Este comando generará un archivo llamado UploadFileRequest dentro de app/Http/Requests/UploadFileRequest. Abre el archivo y échale un vistazo. Verás que es muy sencillo, ya que solo contiene dos métodos: authorize() y rules().

Creando la lógica de validación

Vamos a modificar el stub de la solicitud para que se ajuste a las necesidades de nuestra aplicación. Modifique el archivo para que quede 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 fíjense que el método `authorize()` ahora devuelve `true` en lugar de `false`. Este método decide si se permite o no que la solicitud ingrese a la aplicación. Si se establece en `false`, impide que la solicitud entre al sistema. Este sería un lugar muy útil para incluir cualquier verificación de autorización del usuario o cualquier otra lógica que pueda determinar si la solicitud puede avanzar al controlador. Por ahora, simplemente devolvemos `true` para permitir que cualquier cosa utilice la solicitud.

El otro método, rules(), es donde entra en juego toda la magia en lo que respecta a la validación. La idea es simple: devolver un array que contenga un conjunto de reglas con el siguiente formato:

'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. aquíPara nuestra aplicación de carga de archivos, habrá dos campos que se envían mediante una solicitud POST desde un formulario en el frontend. El parámetro `fileName` debe incluirse en el cuerpo del formulario (es decir, es obligatorio) y se utiliza como el nombre de archivo con el que almacenaremos el archivo (esto se realiza en el controlador; lo veremos más adelante). También especificamos que el nombre del archivo debe ser una cadena agregando el carácter de barra vertical (|) seguido de la palabra "cadena". Las restricciones siempre se delimitan con barras verticales, lo que permite especificar cualquier criterio adicional para el campo en cuestión en una sola línea.

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 obligatorio y Debes ser un archivo. Nota: Si esperáramos que el archivo subido fuera una imagen, usaríamos la restricción de imagen, que limitaría los tipos de archivo aceptados a uno de los formatos de imagen más comunes (jpeg, png, bmp, gif o svg). Dado que queremos permitir que el usuario suba cualquier tipo de archivo, mantendremos la restricción de validación de archivo.

Eso es prácticamente todo lo que hay que saber sobre el objeto de solicitud. Su función principal es simplemente contener el conjunto aceptable de criterios (restricciones) que deben cumplir los parámetros del cuerpo del formulario para poder continuar con la aplicación. Cabe destacar que estos dos campos (userFile y fileName) también deben especificarse en el código HTML como campos de entrada (con el nombre del campo correspondiente al nombre dentro del objeto de solicitud).

Quizás te preguntes: esto define las características que debe contener una solicitud de formulario, pero ¿dónde se verifica realmente el cumplimiento de estas restricciones? Lo veremos 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 process(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'); //so 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 subidos al disco. A continuación, se muestra un desglose del método process() mencionado anteriormente:

• Indique el tipo de la clase de solicitud en el método del controlador que realiza la funcionalidad principal para que podamos validar automáticamente los datos entrantes.
• Extraiga el archivo del objeto de solicitud (ahora validado) dentro del método del controlador.
• Extrae 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.
• Devuelve una respuesta JSON que indique que la solicitud fue exitosa.

La plantilla de la hoja

La última pieza importante de este rompecabezas es la plantilla blade, que contendrá todo el 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('process')}}" 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 asíncrona (para que la página no se actualice). Hay un básico etiqueta sin atributo de método (que explicaremos en un momento) y con un curioso atributo de acción con el valor {{route('process')}}. 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 Blade que realizan diferentes operaciones comunes a la construcción de páginas web y aplicaciones web. Para comprender mejor todas las funcionalidades útiles de Blade, consulta la documentación. aquí. En el caso anterior, estamos utilizando la directiva de ruta para generar un URL para el envío de nuestro formulario.

Recuerda 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, la busca dentro de la lista de rutas almacenada en caché internamente y genera una ruta completa. URL basado en la definición de esa ruta en el archivo web.php. Para este primer caso, estamos especificando que queremos que el formulario envíe sus datos enviados a /process. URL de nuestra aplicación, que se define como una PUBLICAR ruta.

Lo siguiente que quizás hayas notado es la etiqueta @csrf justo debajo de la etiqueta de apertura del formulario. 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 sean de un origen válido y previene ataques de falsificación de solicitudes entre sitios. Para obtener más información sobre esto, consulta la documentos.

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

Anímate a probarlo y envía algunos archivos a la aplicación usando este formulario. Después, navega a la /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 analicemos lo que hemos hecho en este tutorial de Laravel.

Este diagrama representa la aplicación tal como se encuentra actualmente (sin incluir detalles de alto nivel):

Recuerda que el objeto de solicitud que creamos al principio de este tutorial de Laravel debe tener los mismos parámetros definidos en su método rules que los del formulario en la plantilla blade (si no es así, vuelve a leer la sección "Creación de la lógica de validación"). El usuario introduce el formulario en una página web renderizada mediante el motor de plantillas blade y lo envía. 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 aparte), crea una solicitud AJAX, carga la solicitud con los datos del formulario y el archivo subido, y envía todo a la primera capa de nuestra aplicación: la solicitud.

El objeto de solicitud se rellena asociando los parámetros del método rules() con los parámetros del formulario enviado, y luego se validan los datos según cada regla especificada. Si se cumplen todas las reglas, la solicitud se pasa al método del 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 realiza el trabajo. Una vez que llegamos al controlador, ya sabemos que la solicitud ha pasado la validación, por lo que no es necesario volver a comprobar si el nombre de archivo proporcionado es, de hecho, una cadena o si el parámetro userFile contiene algún tipo de archivo. Podemos continuar con normalidad.

El método del controlador obtiene los parámetros validados del objeto de solicitud, genera un nombre de archivo completo concatenando el parámetro `fileName` con la extensión original del archivo del usuario, guarda el archivo en un directorio de la aplicación y devuelve una respuesta simple codificada en JSON que verifica que la solicitud fue exitosa. La lógica de jQuery recibe la respuesta y realiza algunas tareas adicionales relacionadas con la interfaz de usuario, como mostrar el mensaje de éxito (o error) durante 5 segundos y luego ocultarlo, además de borrar las entradas anteriores del formulario. De esta manera, el usuario sabe con certeza que la solicitud fue exitosa y puede cargar otro archivo si lo desea.

Además, observe en el diagrama anterior dónde se traza la línea divisoria entre el cliente y el servidor. Este concepto es fundamental para su comprensión y le ayudará a resolver problemas futuros al gestionar, por ejemplo, múltiples solicitudes asíncronas que pueden ocurrir simultáneamente. La separación se encuentra justo en el límite del objeto de solicitud. Este objeto 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 recibidos desde el navegador web. Si se consideran válidos, continúa hacia el controlador. Todo lo anterior se encuentra en el front-end (el término "cliente" se refiere literalmente al ordenador del usuario). La respuesta se devuelve desde la aplicación al lado del cliente, donde nuestro código jQuery la espera pacientemente y realiza algunas tareas sencillas de interfaz de usuario una vez recibida.

También hemos abordado muchas preguntas frecuentes importantes. Preguntas de entrevista relacionadas con Laravel y PHP para que los candidatos nuevos y experimentados consigan el trabajo adecuado.

Preguntas Frecuentes