Por lo general, contar con un modelo de datos que tengan diferentes estados por lo que vamos pasando es algo bastante normal. Pensar en conceptos como artículos de un blog por ejemplo, que primeramente se crean como borrador y luego, son derivados a editores, quienes los controlan, corrigen y toman decisión de publicar estos artículos o no, o pensar en concepto más complejos como podrían ser las decisiones de otorgar créditos a usuarios de una entidad financiera, nos llevan a pensar en entidades que manejan un “estado”.

El concepto de cambio de estados es en realidad bastante sencillo de entender, pero es muy común ver códigos de desarrolladores repletos de if, esparcidos por toda la aplicación para ir evaluando y cambiando estos objetos de un  estado a otro.

Esto se complejiza más aún, cuando a demás de solo el cambio de estado, hay que controlar permisos de acuerdo a los roles de los usuarios para realizar ciertos cambios de estado o lo que comúnmente conocemos como acciones de los usuarios dentro de un concepto de proceso de negocio.

Para buscar una definición sencilla de entender, simplemente hay que pensar en un workflow o flujo de trabajo, como la definición de rutas posibles, acciones y cambios de estados para objetos que van avanzando en la lógica de ese negocio en particular.

En el ejemplo que venimos viendo, esto aplica para los comentarios de las conferencias que, como vimos en los capítulos anteriores, deben pasar por una verificación para filtrar comentarios de tipo spam.

Vamos a agregar un poco más de complejidad sobre esto para hablar sobre este componente de symfony, que viene a darnos una mano para evitar los famosos códigos de tipo spaguetti, esparcidos por toda la aplicación y que lo único que hacen es complicar más la lectura y el mantenimiento de nuestros sistemas. Desde ya hace varios años venimos comentando que la lógica del negocio debe estar separada de las vistas, cosa que para los desarrolladores php que venimos hace varios años trabajando con este lenguaje, recordarán que antes estaba todo en la misma página y que los modelos de tipo model-view-controller nos ayudan a solucionar. A este concepto, vamos a sumar una división más, separando de la lógica del negocio relacionada a validaciones y cálculos, todo lo relacionados a los flujos de trabajo y control de estado por los que pasa nuestro modelo.

Para esto, vamos a modificar lo que venimos haciendo con el verificador de spam, agregando al administrador del sitio como la persona, que luego de tener un primer filtro automático con el servicio de akismet, tendrá que tomar la decisión de publicar o no el comentario.

De esta forma, un comentario siempre iniciaría con el estado submitted o enviado, luego el verificador de spam de forma asíncrona, como lo vimos en el capítulo anterior, analiza el comentario para determinar si no es spam, si es potencialmente un spam o si lo reconoce efectivamente como spam y lo rechaza directamente.

En caso de no rechazarlo automáticamente, el usuario administrador del sitio deberá ser el que decida si el comentario es lo suficientemente bueno para publicarlo cambiado el estado a publicado o en caso contrario rechazarlo manualmente.

En este capitulo nos vamos a centrar en la primera parte, definiendo el workflow de trabajo y en el siguiente vamos a involucrar el administrador del sitio.

En el siguiente video, vamos a continuar con el procesamiento del workflow, enviando alertas por correo electrónico a los administradores del sitio, para tomar las decisiones sobre los comentarios y accionar los siguientes pasos sobre nuestro flujo de trabajo.

Otros artículos de esta serie

  1. Lista de reproducción en nuestro canal de Youtube
  2. Symfony 5: La Vía Rápida | Paso 1 – Revisando tu entorno de trabajo
  3. Symfony 5: La Vía Rápida | Paso 2 – Presentando el proyecto
  4. Symfony 5: La Vía Rápida | Paso 3 – Desde cero hasta producción
  5. Symfony 5: La Vía Rápida | Paso 4 – Git, composer y Symfony Flex
  6. Symfony 5: La Vía Rápida | Paso 5 – Solucionando problemas
  7. Symfony 5: La Vía Rápida | Paso 6 – Creando nuestra primera página
  8. Symfony 5: La Vía Rápida | Paso 7 – Creando una base de datos con docker
  9. Symfony 5: La Vía Rápida | Paso 8 – Definiendo la estructura de datos
  10. Symfony 5: La Vía Rápida | Paso 9 – Configurando el panel de administración
  11. Symfony 5: La Vía Rápida | Paso 10 – Construyendo la interfaz de usuario
  12. Symfony 5: La Vía Rápida | Paso 11 – Almacenando las sesiones en redis
  13. Symfony 5: La Vía Rápida | Paso 12 – Escuchado eventos (events and subscribers)
  14. Symfony 5: La Vía Rápida | Paso 13 - Gestionando el ciclo de vida de los objetos de doctrine
  15. Symfony 5 La Vía Rapida | Paso 14 - Formularios - Parte 1
  16. Symfony 5 La Vía Rápida | Paso 14 - Formularios - Parte 2 - Subida de archivos
  17. Symfony 5 La Vía Rápida | Paso 15 - Asegurando el panel de administración
  18. Symfony 5 La Vía Rápida | Paso 16 - Previniendo spam con una API
  19. Symfony 5 La Vía Rápida | Paso 17 – Pruebas Automatizadas
  20. Symfony 5 La Vía Rápida | Paso 18 – Volviéndonos Asíncronos
  21. Symfony 5 La Vía Rápida - Paso 19 - Tomando decisiones con un workflow
  22. Symfony 5 La Vía Rápida - Paso 20 - Envío de correos electrónicos a los administradores
  23. Symfony 5 La Vía Rápida | Paso 21 - Almacenando en caché para mejorar el rendimiento

¿Quieres comprarme un café?

  • Bitcoin
  • Ethereum
Scan to Donate Bitcoin to bc1qevxv68nfq427zfkwdjg7802dt00t3h3ulq0rxa

Dona Bitcoin a NeuroSimbiosis

Escanea el código QR o copia la dirección de abajo para realizar donaciones

Scan to Donate Ethereum to 0x47742BE8B21052ce25b33d6A0e09113826AF341f

Dona Ethereum a NeuroSimbiosis

Escanea el código QR o copia la dirección de abajo para realizar donaciones

Deja un comentario