La primera aplicacion

La estructura de Symfony

Toda la aplicación se desarrollará en el directorio src. Aquí es donde escribiremos todo el código.

El framework Symfony utiliza una estructura bien conocida: la estructura MVC. MVC significa: Modelo, Vista, Controlador.

Detallemos un poco estos tres elementos de la estructura.

Los controladores

Todos los controladores se crearán en la subcarpeta: src/Controller. Por ahora, esta carpeta está vacía.

Creemos, por ejemplo, un controlador TestController para probar nuestra aplicación. En la ventana del terminal, escriba el siguiente comando:

php bin/console make:controller TestController 

Es posible que obtenga el siguiente error:

En este caso, su instalación no ha integrado una biblioteca llamada Symfony MakerBundle. Por supuesto, debe usar Composer para instalarla:

composer require symfony/maker-bundle --dev 

 APP_ENV=dev 

php bin/console make:controller TestController 

Esta vez, debería salir bien.

El controlador TestController se crea en la carpeta src/Controller. Examinemos el código...

Las vistas

La vista es el archivo final que genera la página destinada a ser visualizada por el usuario.

Está compuesta de HTML, CSS, JavaScript y todos los elementos que serán interpretados por el navegador del cliente.

La vista también puede contener pequeñas instrucciones de un lenguaje de plantillas llamado Twig. Este lenguaje permite realizar operaciones en la vista tal y como lo haríamos en una página PHP. Por ejemplo, Twig permite definir variables, hacer bucles, colocar instrucciones condicionales, pero de una manera mucho más sencilla que con PHP. El objetivo es separar la parte de desarrollo en PHP de la parte front en HTML, CSS...

Así, alguien que domine Twig no necesita desarrollar en PHP para implementar el diseño del sitio.

Todas las vistas se almacenan en la carpeta templates de la aplicación. Actualmente, la carpeta templates contiene una subcarpeta llamada test que se ha generado al crear el controlador TestController. Contiene la vista index.html.twig.

Observamos la presencia de otro archivo: base.html.twig, en la carpeta templates. Esto es lo que llamamos un layout. Es una vista que servirá de esqueleto a otras vistas (ver capítulo El motor de plantillas Twig).

Abramos el archivo templates/test/index.html.twig y examinemos el código:

{% extends 'base.html.twig' %}  
  
{% block title %}Hello...

Los componentes de HttpFoundation

Todo acceso a una aplicación web se realiza mediante una solicitud HTTP. Sin entrar en detalles, una solicitud HTTP se compone de una cabecera, que contiene información (como, por ejemplo: el nombre de dominio del sitio, el tipo de contenido transmitido...), y de un cuerpo (body), en el que se envían los parámetros que hay que transmitir.

La respuesta del servidor después de ejecutar la solicitud tiene la misma sintaxis. También contiene una cabecera que especifica una serie de información y el código HTML de la respuesta que será interpretado por el navegador.

Estos dos elementos, con toda su información, se traducen en Symfony mediante componentes de la biblioteca HttpFoundation. Estos componentes son dos clases existentes: la clase Request y la clase Response. Consulte el capítulo Lenguaje orientado a objetos, sección Las clases, si ha olvidado la noción de clase.

El uso de estas dos clases Request y Response es muy práctico, ya que podemos encontrar fácilmente los parámetros de la solicitud transmitida o definir los parámetros de la respuesta transmitida.

Pero ¿cómo acceder a estas dos clases de Symfony?

Es posible acceder a ellas utilizando su espacio de nombres correspondiente:

 <?php  
use Symfony\Component\HttpFoundation\Request;  
use Symfony\Component\HttpFoundation\Response;...

El objeto Request

Hablaremos del objeto Request, aunque esto no sea del todo exacto. En realidad, se trata de un objeto instanciado a partir de la clase Request.

Para usar el objeto Request en una acción, es necesario transmitir este objeto en los parámetros de la acción.

Tomemos como ejemplo la acción index() del controlador TestController. Para usar el objeto Request, primero debemos declarar su espacio de nombres:

use Symfony\Component\HttpFoundation\Response; 

luego, puede usar el objeto $request con la inyección de dependencias en el método index:

use Symfony\Component\HttpFoundation\Request;  
class TestController extends AbstractController   
{   
        #[Route('/test', name: 'app_test')]  
        public function index(Request $request)   
        {... } 

Este uso puede parecer extraño al principio.

¿Cómo se instancia el objeto $request?

El objeto $request se instancia automáticamente porque está precedido por el nombre de la clase Request. Symfony se encarga de todo.

Dentro de la acción, tiene toda la libertad para consultar este objeto $request. Por ejemplo, para obtener el nombre de la solicitud, puede usar el método getPathInfo().

Puede probar este método incluyendo el siguiente código en su controlador TestController:

<?php  
  
namespace App\Controller;  ...

El objeto Response

Ahora es el turno de los objetos instanciados a partir de la clase Response.

El objeto Response define la respuesta que se enviará al navegador del cliente.

A diferencia del objeto Request, debe instanciarse dentro de la acción del controlador. He aquí un ejemplo de uso del objeto Response:

<?php  
  
namespace App\Controller;  
use Symfony\Component\HttpFoundation\Request;  
use Symfony\Component\HttpFoundation\Response;  
  
use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;  
use Symfony\Component\Routing\Annotation\Route;  
  
class TestController extends AbstractController  
{  
    /**  
     * @Route("/test", name="test")  
     */  
    public function index(Request $request)  
    {  
          
        $reponse=new Response('Bienvenido a Symfony');   
        return $reponse;   
    }  
} 

La acción index() devuelve la respuesta, que seguirá su curso para ser transformada en una respuesta HTTP. Esta vez, no necesitamos el método render(), que hace referencia a una página Twig.

Al ejecutar la solicitud localhost:8000/test, obtendrá la siguiente visualización:

¿Qué ocurre cuando la acción llama a una vista Twig?

Es el método $this->render(...) el que genera el objeto Response enviado.

Por lo tanto, una acción siempre devuelve un objeto Response. Atención: si omite devolver este objeto Response, obtendrá un error de Symfony. El tipado impone que todas las acciones del controlador devuelvan un objeto de tipo Response.

El método $this->render se encuentra en la clase AbstractController. Al consultar...

Las variables de sesión

1. La utilidad de las variables de sesión

Cuando un cliente realiza una solicitud HTTP, esta es recibida por el servidor, que la procesa y envía una respuesta al navegador del cliente.

Cada solicitud es independiente de las demás.

No hay información que persista de una solicitud a otra. Los parámetros y todo lo que envíe al servidor solo pueden utilizarse en la solicitud que los contiene.

A veces es necesario conservar información específica del cliente que está conectado. Por ejemplo, si su cliente realiza un pedido de productos, sería útil conservar el estado de su carrito de compras de una solicitud a otra.

Este estado es específico para cada cliente. Incluso si la información se guarda en el servidor (por ejemplo, en una base de datos), es necesario identificar la que corresponde al cliente conectado.

Para ello, el servidor envía un identificador de sesión, que se almacena en el navegador de cada cliente (es una cookie). Con este identificador, puede identificar al cliente cada vez que se conecta y mostrarle su carrito de compras.

El almacenamiento de este identificador de sesión dura mientras el navegador está abierto y desaparece al cerrar el navegador. Si el cliente se vuelve a conectar, deberá solicitar un nuevo identificador. Esta volatilidad del identificador de sesión evita posibles vulnerabilidades de seguridad, como el robo del identificador de sesión.

 $sesion = $request->getSession(); 

 $miVariable...