Creando un Foro con el MicroKernelTrait de Symfony (Parte 3)
Esta es la tercera parte de una serie de artículos donde se explicará paso a paso el desarrollo de una aplicación muy simple utilizando el MicroKernelTrait de Symfony.
Esta es la tercera parte de una serie de artículos donde se explicará paso a paso el desarrollo de una aplicación muy simple utilizando el MicroKernelTrait de Symfony.
Esta es la segunda parte de una serie de artículos donde se explicará paso a paso el desarrollo de una aplicación muy simple utilizando el MicroKernelTrait de Symfony.
En esta ocasión voy a escribir una serie de artículos en donde se describirá paso a paso el desarrollo de una aplicación muy simple utilizando el MicroKernelTrait de Symfony, la cual será un Foro donde los usuarios podrán hacer preguntas y responder las preguntas de otros usuarios.
La idea de este post es demostrar como podemos pasar opciones a un campo de formulario que se crea por medio de un escucha de eventos de formularios, para así dar a conocer el potencial que ofrece el componente de formularios, el despachador de eventos y el OptionsResolver.
Este artículo intenta servir de guía para el entendimiento y la realización de formularios que tienen partes dinamicas (selects dependientes, campos adicionales dependientes, etc).
En las aplicaciones construidas con symfony siempre es necesario que los formularios tengan un aspecto visual adaptado al diseño general de la página.
Continuando con el post sobre el uso de un Despachador de Eventos (Ejemplo Practico), crearemos ahora un listener que verifique el estatus del usuario antes de aprobarlo, para así evitar que se le reenvie un correo a un usuario previamente aprobado.
Las validaciones en Symfony se trabajan con el componente validator, y realmente son muy sencillas de definir ya sea en yaml, xml o usando anotaciones.
Continuando con el post sobre el uso de un Despachador de Eventos, crearemos un ejemplo que permita mostrar como podemos usarlo cuando desarrollamos con Symfony.
Twig es una libreria de templates para php, que es muy utilizada en la actualidad, el framework Symfony lo utiliza por defecto para la parte de las vistas, y yo personalmente lo uso en todos los proyectos php que construyo.
Uno de los principios de SOLID es el de Open-Closed (Abierto-Cerrado abierto a extension, cerrado a modificación).
Recientemente he estado trabajando en una aplicación que ya tiene un buen tiempo desarrollada, la labor de nuestro equipo de trabajo en este proyecto es implementar un rediseño de la plataforma, y mejorar/ajustar algunas funcionalidades.
Este componente permite implementar el Patrón Observador mediante el uso de una clase (EventDispatcher) que contiene a los escuchas de eventos y los llama cuando se dispara algún evento en particular.
Esta es una continuación del post sobre el uso del Componente DependencyInjection, y se hablará sobre la creación de extensiones, que no son más que clases que nos permiten agregar y modificar servicios y parametros al contenedor.
Creo que ya existe en la web bastante información de como el framework symfony implementa la inyección de dependencias, definiendo clases llamadas servicios que se encuentran disponibles en un contenedor.